debian server login 變慢的問題

已經有好一陣子，連到自己的伺服器，不管是做 sudo su - 或是用 ssh 連過去，或是用 scp 拷東西過去，都要等上十幾秒才會回應。今天去爬了文，找到原因。d-bus 有變化時，要重新執行

systemctl restart systemd-logind

就解決了

Running gcin on ezgo13 (kubuntu 16.04, qt5 問題)

雖然裝上了 gcin-qt5-immodule 但是發現 qt5 的程式一直都還是無法叫出 gcin

後來研究之後成功了
我的做法是：

1. 移除 fcitx (我不確定是否必要，但放多個輸入法在裡面反正是不會有好處) 並安裝 gcin，記得要安裝 gcin-qt5-immodule

2. 修改 /etc/default/im-config 中 IM_CONFIG_PREFERRED_RULE 把 fcitx 通通改成 gcin (我也不確定這個步驟是否必要)

3. 執行 im-config 選擇預設 default

5. 重點：/usr/share/im-config/data/26_gcin.rc 中，在 QT4_IM_MODULE=xim 下面加上一行

QT5_IM_MODULE=xim

重新登入，搞定！

不過我發現重新開機之後 KDE 第一次會無法登入，卡在 splash ，要切到 console 去重啟 sddm 才能順利登入。後來再爬了一下文，修改 /usr/bin/startkde 中
有一個決定 $qdbus 的地方，在 else 的地方
qdbus=qdbus 改成 qdbus="qdbus -qt=5"

至少剛剛重新開機有順利登入了！

pptpd server on debian

在 debian 設定 pptpd server 時，要注意除了 port 1723 要開之外，protocol gre 也要打開。

OOXML / 微軟舊封閉格式轉成 ODF -- 為何不要用微軟的 Office 來做這件事？

雖然國發會的說明會投影片中告訴大家微軟也支援 ODF，但是就幾個手上的例子，還有我跟國際社群實際接觸觀察到的現象，在此分享給大家。

先說結論：想要將微軟格式轉成 ODF，最好還是用新一點版本的 LibreOffice (5.1.x, 5.2, 5.3...) 轉出來的結果成功率較高。不要用微軟的 Office 來另存新檔。

進入正題：

1. 大約半年多前，我請目前台灣 ODF 第一把交椅的講師幫我用微軟 Office 2010，將幾個簡單到略微複雜的微軟 docx/pptx/xlsx 另存成 ODF 檔給我測試。不過當時因為國發會想要找到的是一個可以驗證 ODF 格式合法性的工具，所以我拿到這些檔案的主要目的是要測試這個：

https://odf-validator.rhcloud.com/

我拿這兩者做對照實驗：

第一組：講師給我的微軟 Office 原檔與直接另存新檔產生的 ODF 檔

https://goo.gl/qAGYlP

第二組：2016 年宜蘭縣政府 ODF 教育訓練公開招標文件，這時經過去年我們對宜蘭縣政府一年的教育訓練與工作導入輔導後，他們直接採用 LibreOffice 產生的 ODF 檔

https://goo.gl/y3vHxL

測試方式：選擇 ODF 1.2 Extended conformance 並開起 Log verbose

結果：

第二組中，LibreOffice 直接產生的 6 個檔裡有一個未通過。我以此發了一個 bug issue:

https://bugs.documentfoundation.org/show_bug.cgi?id=98520

測試結果：https://goo.gl/TH80vM

而第一組中，微軟 OffiCe 存成的 ODF 則全軍覆沒，沒有一個檔案通過。
（測試結果附在壓縮檔裡）

另外有興趣的朋友可以自己用微軟 2010 或 2013 來試試看。直接拿微軟開啟微軟自己產生的 ODF，跟拿 LibreOffice 開啟微軟產生的 ODF ，結果是否有所不同。我自己沒有微軟的 Office，所以沒做過這方面測試。但講師測過，結果相信也不需要我多說。

2. 去年九月微軟台灣葉光釗技術長在 COSA 舉辦的開放系統論壇上親自承認微軟存成 ODF 時有加料。我人在現場，也有懂這方面的社群朋友在場。雖然他的投影片裡並沒有放這部份，而是只講到這裡：

(來源： http://www.cosa.org.tw/images/104OSS/04-%E8%91%89%E5%85%89%E9%87%97MS%20ODF%20Overview.pdf )

實際上 ODF 並非 "provides no extensibility mechanism". 它們有一套流程，在你使用 extension 後必須與 OASIS 申請，經由數道程序的討論後，進入 ODF 標準中。這裡是 LibreOffice 目前所使用的所有 extension：

https://wiki.documentfoundation.org/Development/ODF_Implementer_Notes/List_of_LibreOffice_ODF_Extensions

舉一個比較新的例子，大家可以搜尋 Core commit 9c2a80，對此 issue 經過一番討論之後，最後投票決定接受為 RESOLVED 並進入 ODF 1.3。

至於微軟有沒有遵循這個規範？

我剪一小段我跟另一位 LibreOffice 核心開發者，也是這次推動英國政府以 ODF / LibreOffice (GovOffice) 為規範的推手 Michael Meeks 跟我的一小段對話。因為英國政府曾經下令要求微軟儲存 ODF 時必須遵循英國政府所使用的 ODF 規範（含 extension），而：

Me: (And I'm very curious, do Microsoft *really* obey this list and export only the extensions list here?)

Michael: Certainly not =)

3. ODF Committee 成員 Jos van den Oever，也是荷蘭政府在 ODF Committee 的代表，跟我討論今年 ODF Plugfest 時說，微軟每年都會參加 plugfest，但從未下海做過任何測試。

這封信的部份原文（前面是關於我參加今年 ODF plugfest 的事）如下：

At the plugfest we usually have a talks part and a testing part. At thelast plugfest we wrote a long report with interoperabilty issues [1]. Weappreciate if attendees contribute tests. You can send them to mebeforehand and I'll make sure the issues will be discussed.Ideally, we'll run the issues through our testing system. If you havesoftware which you want to have hooked up into that let me know.If you join, it would be great to have talk by you of about 20 minutesabout the status in Taiwan. 

Microsoft employees have attended a few times but usually do not join inthe the technical part and neither do employees from Apple or Google.This is a clear message from them that they do not care aboutinteropability. 

Microsoft does attend the weekly ODF standardization teleconference.They are usually simply observing. You are right to advise people to notuse MS Office for ODF. Google Docs is even worse.

再拿葉技術長的投影片來打臉一下：

可知他們對所謂的 "主動舉辦和參與 ODF interoperability" 是怎麼一回事情。

其實我在所有我所主講的說明會場合都說得很清楚，撇開預算問題不談，只要微軟能確實遵循 ODF 1.2 規範，儲存成的 ODF 檔不會造成其他軟體讀取與編輯的困擾，那麼大家使用微軟另存 ODF 是沒有關係的。這是最理想的狀況，只是目前微軟並未採取此一友善政策。

所以，目前為止，還是請大家如果有轉檔需求，請直接使用 LibreOffice（新版的當然表現會比舊版好一點），而不要採用微軟 Office 另存新檔成 ODF 的方式。

LibreOffice Conference 2016

This year LibreOffice Conference 2016 was held again (yes, again) in Brno.  I said "again" because that two years before I also went to Brno for Akademy 2014.  But Brno is a cute city (more like a town to me) and I like there very much, and this year we had three people going there together.

The scene in Praha and Brno kept making me recall my memory, like the train station and locked restrooms.

In the morning of the community workshop I planned to go to the city center around Brno train station with my partners Jeff Huang and Mark Hung.  However I met Italo in the hall of the hotel and he asked me if I would like to attend the certification meeting.  It was my honor and I was happy to, so I  kicked my partners out and attended the meeting.

Certification Meeting

In the meeting Italo mentioned that the ODF/LibreOffice migration in Taiwan is important because it proves that ODF/LibreOffice is not only suitable to European and American countries.  We also talked about some important issues like to make trainer's certification more localized, and to make sure that being a TDF member is NOT a need to apply for certification.

This year the venue was very beautiful.  Actually it is the most beautiful venue among all the conferences I have ever attended.

The venue of LibreOffice Conference 2016

In the welcome party we met friends from Japan, Naruhiko and Shinji.  But poor Naru spent some day in the hospital... Fortunately he is okay eventually.

Jeff, Mark, Shinji and Naruhiko

This year I gave two talks.  One is about the LibreOffice macros.  I told people how I found the documents and then realized that we need some more tutorials which are appropriate for newbie macro coders.

My first talk

My second talk was still about the progress of ODF/LibreOffice migration in Taiwan.  Since my presentation last year more and more city/county governments started their training courses and communication phases.

My second talk

ODF migration map in Taiwan

The most exciting thing in this conference for me was that Italo showed this slide:

Our hard work of promoting and migrating ODF in Taiwan was seen in the world.  I hope that in a few years the migration map can be all green, and the world can see that ODF and LibreOffice are the most appropriate choices.

So, I'll keep going my work on this, and wish I can give you more good news in Rome next year!

用 7za 解開 Windows 上 Big5 編碼的 zip 檔

關鍵是在使用 ppa:frol/zip-i18n 裡面，加入 libnatspec0 支援的 p7zip-full, zip & unzip


7za x -o{Directory} <zipfile>

用

7za x -o`kdialog --getexistingdirectory $HOME` <zipfile> 就可以先開一個對話框選擇存放目錄，再把它解出來。

在 kububtu 16.04 上裝 KDE applications 16.04

1. 套件庫： ppa:kubuntu-ppa/staging-kdeapplications
2. apt-get update; apt-get dist-upgrade

但是有三個重要套件會被移除掉：calibre, musescore, fcitx-frontend-qt5
原因是 kubuntu 16.04 中這三個套件是相依於 qt 5.5.1，但 kde applications 16.04 用的是 qt 5.6.1

所以被移除之後，要到開發中套件庫把它們加回來：

echo "deb http://mirrors.kernel.org/ubuntu/ yakkety main universe" >> /etc/apt/source.list

apt-get update; apt-get install calibre musescore fcitx-frontend-qt5

kubuntu 獨立後，感覺整個 QA 品質變好差 :( 

為什麼要學習程式語言？

說真的，檯面上那麼多人喊得那麼大聲，我覺得我來推正當性比其他檯面上的人都高多了...

ezgo13 (LXDE) develop note

從 Original Lubuntu 16.04 開始：

• locale-gen zh_TW.UTF-8
• locale-gen zh_TW
• /etc/apt/source.list
• /etc/resolv.conf
• recv-keys 4CD565B5 from pgp.mit.edu
• add ezgo.list to /etc/apt/source.list.d
• echo "blueman hold" | dpkg --set-selections  # 因為在 chroot 環境下無法 reload dbus 所以會更新失敗
• apt-get install vim vim-runtime vim-gtk vim-scripts # 純粹拿個人喜好強加在使用者身上，爽
• apt-get dist-upgrade  #記得先 mount proc, sys, dev/pts
• change ubiquity-slideshow-ezgo
• apt-get install oxoffice5 oxoffice5-writer oxoffice5-calc oxoffice5-impress oxoffice5-math oxoffice5-base oxoffice5-zh-tw
• apt-get install firefox-locale-zh-hant language-pack-zh-hant language-pack-gnome-zh-hant 
• apt-get install fcitx-googlepinyin fcitx-chewing fcitx-libs-qt5 fcitx-libs-qt fcitx-table-array30 fcitx-table-array30-big fcitx-table-cangjie3 fcitx-table-cangjie5 fcitx-table-boshiamy fcitx-tools fcitx-ui-light
• apt-get install ezgo-lxde ezgo-menu  # pidgin.desktop 會造成錯誤

ezgo13 KDE develop note

來寫點開發紀錄吧

1. 之前 ezgo12 用 Kubuntu 14.04，legacy mode 開機畫面只要改 isolinux/gfxboot.cfg 把 hidden-timeout=2 拿掉，加上 foreground=0xFFFFFF 即可。但是用 16.04 做 ezgo13 時，同樣的方法卻失效了。後來發現是要改 isolinux/bootlogo。它本身是一個 cpio 起來的壓縮檔，所以要
   
   mkdir aa
   cd aa
   cpio -i < ../bootlogo
   
   解開來之後，之前在 isolinux 下修改的通通變成在這裡改（例如 lang, splash.pcx 等檔案），然後
   
   find . | cpio -o -H bin > ../bootlogo
   
   壓回去，結果就成功了。
2. Plasma5 的 config 不再集中在 /usr/share/kde4，而是通通分散放到 /usr/share 下。家目錄中的 config 也是，之前都集中在 ~/.kde 或 ~/.kde4，現在則是通通放到 ~/.config 下。照開發團隊說法這樣「才符合標準」，但這樣要整個 reset 回一個 clean 的 KDE Plasma 5 環境變得非常麻煩...
3. Plasma 5 似乎不吃 XDG_MENU_CONFIG，所以要手動改 menu  :(  把 ezgo-applications.menu 連到 kf5-applications.menu
4. 安裝 ezgo-kde5 之後，還要修改以下地方：
1. /usr/share/plasma/desktoptheme/*/metadata.desktop ，把下面 [Wallpaper] section 的 defaultWallpaperTheme 改成 ezgo，大小改成 1920x1080
2. /usr/share/plasma/layout-templates/org.kde.plasma.desktop.defaultPanel/contents/layout.js 把它用 /usr/share/ezgo/ezgo-kde5/defaultPanel.layout.js 覆蓋掉。注意不能用 symlink。
3. /usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/components/artwork/background.png 把它用 /usr/share/ezgo/ezgo-artwork/default-dm/1920x1080.png 換掉。
4. /usr/share/plasma/shells/org.kde.plasma.desktop/contents/layout.js 把它用 /usr/share/ezgo/ezgo-kde5/desktop.layout.js 覆蓋掉。注意不能用 symlink。
5. 安裝 oxoffice 的指令：
   
   sudo apt-get install oxoffice5 oxoffice5-writer oxoffice5-calc oxoffice5-impress oxoffice5-math oxoffice5-base oxoffice5-zh-tw