Software Cinema

Installation assumptions :

• On Ubuntu 16.04.1 LTS
• Followed : http://taigaio.github.io/taiga-doc/dist/setup-development.html
• It's a little different form setup-production.html ...
• Using taiga-back @ github, cloned 2017-01-14, taiga-front @ github, cloned 2017-01-16

Back-end Issue :

• django.db.utils.OperationalError: FATAL:  Peer authentication failed for user "taiga"
• check your settings/local.py for password configuration of user "taiga"
• If that doesn't work
• check your /etc/postgresql/9.x/main/pg_hba.conf
• revise the line "local all taiga peer" from space-based separation to tab-based separation
• service postgresql restart

剛剛才看到 Mageia 的消息, 忽然驚覺自己的想法也有些轉變.

在幾年以前, 雖然覺得難度很高, 但是基本上我算是 "統一 Linux 版本" 的隱性支持者. 姑且不論要用什麼方式統一, 例如有單一組織發行標準版, 或是針對 Distro. 架構訂出標準等等. 希望就此解決使用者會感覺混亂, 沒有單一品牌, 不易推廣等等問題.

但是上個月初, 因為一些誤會, 導致剛安裝好的 Mandriva 2010.1 RC 被我砍掉重裝了. 因為還有工作要完成, 沒有辦法等我慢慢釐清問題, 很不安地先備份資料後選擇重裝 Mandriva 2010.1 Stable. 因為我以前使用的習慣不是很好, 導致每次更新或重新安裝新版本, 在回復過去的工作環境上都需要六個小時或以上的時間.

但是這次因為距離上次更換為 Mandriva 2010.1 RC 的時間尚短 (不到幾個月), 大部分資料都只存在 /home 裡面, 額外的 Library 也幾乎都是用 Package Manager 安裝的. 因此在重新安裝之後, 再次透過 Package Manager 勾選所有我需要的 Package, 安裝後會動取用 /home 裡面的 Configurations & Profiles, 在一個小時內我就完成了整個安裝 + 幾乎整個環境回復.

這次的經驗是很好的, 因為我花了很少的時間得到了更新而穩定的系統, 同時我的資料以及各種 Configurations & Profiles 都沒有失去.

這個完全從使用者角度來看的經驗, 或許反映出是否有統一的版本或架構其實並非重點...

生物多樣性 -- 版本多樣性很重要, 但是對於使用者來說, 前提是不會因為版本多樣性而造成額外的負擔, 即便是版本多樣性可以帶來任何 Distro. Makers 所宣稱的好處.

所以什麼 "Domain-Specific", "More Stable", "The Plan of Company"... 一堆理由或許都敵不過 "Replaceable" 的重要性.

滿足 "Replaceable" 使用者就可以自由地轉換 Distro., 哪怕你的團隊就只發行一個版本的 Distro. , 只要他對於轉換提供某種程度以上的保證, 使用者就可以放心的使用, 不用挑什麼 "穩定長久地發展" 等等...

人都是不可靠的, Distro. 發展團隊也是. Mageia 也不能保證 Mandriva 的使用者改用他們的 Distro. 就不會在兩三年後被迫改回用 Mandriva 或是其他的 Distro. 以得到比較新版的整合. 相對來說, 如果 Mageia 可以跟我保證, 在某個時間點, 我可以知道轉移其他 Distro. 的 "Replaceability" 有多少, 會是更有意義的保證.

因為重新安裝了新版的 Mandriva, 自然 Picasa 也要重裝 ... 時間過得很快, 沒想到已經有 Picasa 3 beta 了, 鑑於個人對於 Picasa 2 for Linux 的諸多不滿, 自然想試試看 Picasa 3 ...

結果還是一樣, 到底為什麼 Picasa 要設計成一啟動就不受控制地 Scan 我的所有大大小小資料夾呢 ? 而且介面對於 zh-TW 的支援還是很有問題阿...

正向上傳去澎湖的一些照片的時候, 又遇到 Web Connection Failed 的問題, 訊息大致是像這樣:


Login failed
HttpOpenRequest failed (12157) -
https://www.google.com/accounts/ClientAuth [13]
.........

找了一下 Google, 補上 openssl-devel 的安裝即可解決. 在 Mandriva 2010.1 下的話, 相對就是 libopenssl-devel package

不過感到奇怪的是, 因為原本 openssl 已經有安裝了, 為什麼 Picasa 還是需要 devel package 呢 ? 如果只是需要 libssl.so 的話, 在 openssl/libopenssl package 裡面應該就已經有了.

難不成在進行 Web Connection 時, Picasa 會作某些 Compilation 動作 ?

不過如果仔細去看 /home/user/.google/picasa/3.0/ , 會發現有以下的錯誤訊息:

fixme:wininet:InternetSetOptionW Option INTERNET_OPTION_CONNECT_TIMEOUT (10000): STUB
fixme:wininet:InternetSetOptionW INTERNET_OPTION_SEND/RECEIVE_TIMEOUT 10000
fixme:wininet:InternetSetOptionW INTERNET_OPTION_SEND/RECEIVE_TIMEOUT 10000
err:wininet:NETCON_init trying to use a SSL connection, but couldn't load libssl.so. Expect trouble.


從最後一個訊息看起來是因為找不到 libssl.so , 因此再回頭去看 Mandriva 2010.1 在 libopenssl 以及 libopenssl-devel 裡面的檔案安裝配置, 會發現 :

libopenssl 安裝完只有 /usr/lib/libssl.so.1.0.0


而 libopenssl-devel 安裝完會建立 /usr/lib/libssl.so -> /usr/lib/libssl.so.1.0.0 ( Konsole 配色 XD )


這樣 Picasa 才能夠找到 /usr/lib/libssl.so 而成功進行 Web Connection.


所以... 應該是可以不用安裝 openssl-devel package, 只要自己在 /usr/lib 裡面建立 softlink 到正確的 libssl.so 檔案位置就好... 不過這只是個人猜測, 懶得移除再嘗試一次了 :p

Unfortunately... after a weekend power blackout, my Philips 200WB monitor could not display anymore in X system.

The booting message on the monitor displays fine, it just got into "SLEEP" mode when the X starts to running, and nothing shows up thereafter.

Changed the runlevel to 3, and logined in command line to check the log, the kdm.log only says: No Screens Found.

The log message may be correct, but it seems odd to me since I could see all the booting messages before the X starts to run...

If you google the message "No Screens Found" plus the keywords linux, mandriva, startx, or whatever, you might found many speculations and possible solutions, such as the corrupted xorg.conf, inconsistent package upgrading, driver problems...

I had no idea what's going on, but I did make some X system upgrades before the blackout, so I guessed maybe one of the speculations is my problem. Therefore I tried these solutions as people suggested on the web:

1. depmod -a & startx to see if it works

2. XFdrake --experts to re-configure the xorg.conf ( actually this works the same as drakconf on Display configuration )

3. Remove the original xorg.conf, use xorgconfig to generate new xorg.conf

4. Set the device and the monitor to generic options

5. Re-install the X system

6. Re-install the Mandriva ... ( Yes I did that !!! Fortunately I made the system and data partitions a clear cut, so the re-installation is quite easy )

And all of these solutions did not work, my monitor still SLEEPED ZZZzzzzzzz after the X starts to run.

Somehow I started to think : Will it be the problem of the monitor itself ?

So I changed the monitor with another Mozo LCD with D-Sub connection. Hell, my desktop is back ~!!

After a cross check, I finally figured out that the problem is on the DVI+ connection of my original Philips monitor. The connection is a DVI-D single link. The end of the link in the monitor side is not locked, and being a little loose.

I check some DVI information on the web, but I really can not figure out how it works and how this would happen. I guess there might be two causes: (1) because of the loose link, the video adapter can not acquire the correct monitor EDID, or (2) because of the loose link, some video signal (TMDS) can not transmit correctly.

Anyway, after I re-connected the DVI-D link and locked it well, the monitor functions correctly as usual :)

So, if anybody has the same problem as me, maybe you can consider check the DVI link before try any complicated solution :p

上週去參加 CSCST 2010 前夕, 我那本來就有點不太聽話的 SCIM 正式掛點了. 原因不詳, 總是當初隨 Mandriva 2007 裝的 SCIM 1.0 很容易在快速切換 Apps. 以及輸入法時陷入短暫 Idle 的狀態, 特別是當 Firefox 參與其中時...

索性移除所有 SCIM 相關 Packages, 整個重裝, 不過結果是只要進 KDE 所有 Apps 都開不起來, 會被 SCIM 或是 SCIM-Bridge 暴衝卡住 CPU, 就算砍掉 SCIM processes 還是會再跑起來. 直到現在我還是搞不懂為什麼 Apps 跑起來的時候都要先跑 SCIM 或 SCIM-Bridge ?

不過參加會議在即, 就先不管他, 直到回來又花了一天才修好. SCIM 跟 SCIM-Bridge 的選擇姑且不提, 在安裝新酷音 chewing 時, 又遇到裝上了, 卻無法開啟 SCIM-setup 來調整的情況, 當然也就無法使用 chewing. 倒是其他的輸入法就沒這問題.

總之, 後來發現 SCIM 重裝跟 chewing 重裝都注意把 .scim 跟 .chewing 先移除或是清空, 否則就出現上面奇怪的情況.

是否利用 Package Manager 移除 Package 時, 應該更 "Smart" 地主動考量 Configurations 一併移除的問題呢 ?

不知道為什麼我的 Mandriva 2008.0 在 Compiz 啟動模式下, RealPlayer 沒辦法正常地播放 RMVB 檔案, 會出現以下的錯誤, 但是關閉 Compiz 模式就沒有問題.

The program 'realplay.bin' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAlloc (insufficient resources for operation)'.
(Details: serial 37 error_code 11 request_code 141 minor_code 19)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)

之前嘗試換不同版本的 Real Player 也無解, 找額外的 MPlayer Codec 安裝也不太順利, 最終在 MacBlog3 發現了一個超級簡易的方法 : 直接把 Real Player 底下的 /codec/* 複製到 /usr/lib/win32 (如不存在請自行建立) 底下就可以了.

不過由於是 share library, 因此不用複製的, 直接利用 link 從 /usr/lib/win32 連結到 /codec/* 應該也可以, 這樣以後更新 Real Player時就可以順便更新 MPlayer 用的 library.

前陣子 Acer 自打嘴巴地推出了 Aspire One, 加上今天看到了 ComputerWorld Blog 上的這篇文章 : PC Vendors Want to Sell You Desktop Linux, 其實很顯然的, 在 EeePC 的成功之後, 不僅是在 Desktop PC 上, 各種 NB, 小 NB, Mobile Device 上, 廠商業者考量採用 Linux 的傾向得到了更為強烈的市場反應支持, 加上 Desktop Linux 系統的成熟, 產品廠商在付出額外的 Desktop Linux 修改成本與降低銷售成本以提高顧客購買率與競爭力之間, 只要能取得有利的平衡, 就是對於他們可行的方案.

反正, 改用搭配 Desktop Linux 是一個進可攻退可守的方案, 君不見 EeePC 還是會推出附有 Windows 的版本嗎 ? 甚至更奸詐的把改裝 Windows 的選項留下來, 任由顧客自己去找盜版的 Windows 進行重新安裝. 或許有很多人是會改裝回 Windows, 不過不管如何, Desktop Linux 的市佔率提高是一定的事情, 只是速度快慢而已.

乘著這個趨勢, 可預見的, 產品廠商還是會持續的考慮採用 Linux, 除非 Microsoft 釋出更有利的方案. 而這會形成一個有趣的現象, 這些本來是整合硬體跟軔體, 然後採用 Microsoft 軟體的產品廠商, 會不會開始做起軟體 ( OS, Desktop, Apps ) 的部份呢 ?

ASUS 的 EeePC 在軟體操作介面上並不是只套用常見的 Linux Desktop, 而是再進提供了 Easy Mode, 以 Task-Oriented 為主. 雖然不是創新的設計, 但是怎麼說也是自家要做的東西, 變成了整個自家產品開發的一部分. 過去我們買 NB 時在 OS 方面沒辦法比, 因為都是一樣的系統跟介面, 所以幾乎都是比同樣價格下硬體的規格, 穩定度, 主要用途適用性, 售後服務等等. 但說穿了, 除了售後服務, 其他大概都差不多, 一般使用者也鮮有機會感受到差異.

但是 Software 就不一樣了. 光是 Desktop 使用介面的設計的差異就會造成使用者極大的不同感受, 更別說對於使用者安裝新軟體的便利性以及常用軟體的穩定性. 這些都會比其他方面對於使用者造成更直接更巨大的影響. 也許在這方面沒有一家公司可以取得獨特的領先地位, 但是誰也不敢落後太多吧 :p

在此考量下, 不知道這些產品公司會不會開始成立自己的軟體部門--有別於過去只有處理軔體跟驅動程式, 以及 MIS 的部門, 而是會負責建立或是修改 Open Source OS, Desktop, 以及 Apps 的部門. 或是採取外包的方式, 有專門的軟體公司來與這些產品公司合作進行 Customization, 就跟過去 Microsoft 的角色一樣.

Either way, Software Rules. ^^

在嘗試修改 FileZilla 的一些 Configuration 時意外發現, FileZilla 在紀錄最近一次的連線時, 居然是採用明碼來紀錄 Password = =

FileZilla 為了方便重新連線到剛剛斷線的 FTP Server, 或是快速進行常用的連線, 會把最近一次的連線資料紀錄在 $HOME/.filezilla/filezilla.xml 的最後面, 在 Last Server 的 Tag 包裹下, 以及最近幾次的紀錄在 $HOME/.filezilla/recentservers.xml 裡面, 在 的 Recent Servers Tag 包裹下 ( 下圖的資料當然全是假的 :p ).

對於 FileZilla 使用來說當然問題不大, 因為只要你能夠用該帳號啟動 FileZilla, 就能夠透過 FileZilla 進行前幾次的快速連線, 看不看的到密碼差別不大. 但是以使用者的角度來說, 因為 filezilla.xml 以及 recentservers.xml 這兩個檔案都是一般閱讀權限, 因此只要使用該帳號執行的程式都有相當的機會去讀取這兩個檔案, 這時候用明碼跟編碼差別就很大了.

不知道 FileZilla 選擇用明碼的理由是甚麼 ? 多想兩秒鐘, 其實你可以編一下碼的.

就在本週之初, 與 FireFox Download Day 同一天, MiningLabs 公佈了一個對於 FireFox 3 的部份效能測試 ( Empirical Study ), 並與 FireFox 2 做了簡單的圖表比較.

大致的重點為 :

• JavaScript 執行效率有顯著改進
• Memory 使用量 FireFox 3 比 FireFox 2 更吃重
• Memory 釋放率 FireFox 3 比 FireFox 2 來的好

這蠻符合我這周來的使用經驗. 基本上 Memory 使用量增多幾乎是必然的, 可以進一步檢驗的是 FireFox 3 所新增的能力與所使用 Memory 的增長之間, 是否維持在一個合理的關係之內. 不過 MiningLabs 並沒有進行這種細部的檢驗.

而 Memory Release 的改善我很明顯的感受到了 :)

以下圖片引用自 MiningLabs.
過去 FireFox 2 在我的系統上經常會飆高到佔用 Memory 40 % ( 約 400 MB ) 以上的可怕情況, 這固然跟我使用習慣有關, 經常是開了 30+ 以上的分頁, 包含許多 PDF 頁面. 但是即便在 Idle 時期也不會降下來, 這就是 FireFox 2 本身有缺點的地方了.

FireFox 3 在本週的使用中, 當我偶爾用到一半刻意開 top 觀察的時候, 多在佔用 Memory 20 % 以下, 而 Idle 時則肯定在 10% 以下. 由於我整天 FireFox 幾乎是不關的, 因此 FireFox 本身 Memory Release 效能的改善也帶動整體工作環境的操作順暢感 :)

最近開始改用短小的 TexMaker 取代 Kile 作為我主要的 LaTex 編輯工具. Kile 的介面實在太雜了, 以我使用特殊語法跟符號的頻率來說, 還是介面簡潔的 TexMaker 比較適合.

不過剛剛才發現在 Mandriva 2008 下, 利用 Package Manager 裝的 TexMaker, 其 Spelling Check ( 使用 Aspell ) 預設居然是採用 zh 語系, 所以用英文寫 paper 時怎樣檢查都不會發現拼字錯誤. 無怪乎我上一篇 research proposal 打完居然都沒發現錯字, 還以為自己變神了 ^^b, 高高興興地就寄給 Advisor. ( 慘了下次 Meeting 要被 Advisor 鞭了 )

要把 TexMaker 的 Spelling Check 語系改回到 en 才能夠正確地對於英文拼字作檢查. 下次重設系統千萬要記得 @@

最近遇到一個問題是 Mandriva 2008 下的 RAR 解壓縮. 因為工作上的需要常常會要解 RAR 格式, 但是 Mandriva 2008 內建的 file-roller 居然不能解 = =

問題拖了一陣子今天終於下定決心解決. 查了一下我猜大概是因為一些 license 的問題所以 Mandriva 2008 沒有直接把 RAR 相關 packages 納入吧, 利用 package manager 也找不到. License 的問題在摩托學園有不錯的討論, 知道了很多相關 packages 之間的考量問題.

不過說真的似乎沒有好選擇, 因為有的 packages 很難找, 或是幾乎無法進行 compilation, 最終只有很不情願的選了 RARLabs 的 RAR 3.71 for Linux , 雖然是 Trail, 但是如果只是使用 unrar 進行解壓縮的話似乎是沒有影響.

下載完 RAR 3.71 for Linux 之後就簡單了, 解壓縮後移到習慣的地方, 例如 /usr/share/rar , 然後把 unrar 使用 soft-link 連結到 /usr/bin/unrar 即可.

這樣一來直接在 command line 下使用 unrar e file.rar 可解壓縮, 而 file-roller 也可以直接支援 RAR 檔案的解壓縮了.

因為最近有需要架設一個多人共同管理的 Blog 系統, 之前試用過的 Joomla ! 在文章發表以及回應邏輯上不太適合, 而 Drupal 的設計又太過 "先進", 所以我正在試用其他的系統中. 因為看起來使用 Lifetype 或是 WordPress 來作多人部落格的使用率蠻高的, 想說先試試看, 沒想到前天在裝設 Lifetype ( 1.2.6 ) 時就遇到奇怪的問題.

為了方便起見, 我是用 LAMPP 作為試用的架設環境, 一切的 Lifetype 安裝都很順利, 但是在使用時會發現檔案無法上傳的問題, 只能夠新增資料夾 ( 在 Lifetype 內的邏輯資料夾, 只會更動 database, 不會在實體硬碟上 mkdir ). 偏偏 Lifetype 一點錯誤訊息也沒給. 在調整過各種可能的權限設定, 改過 Lifetype 內各種可能的設定, 甚至去看了 class/gallery/ 內的部份程式碼之後, 暫時放棄了. ( 話說其實我不太懂 PHP, 但是 PHP 的 class 寫法有點奇怪, 像是把 Functions 以及 Global variables 集結成為一個 class 的感覺, 不像真正的 object )

後來就直接改用 WordPress 試試看. WordPress 的安裝也是相當容易, 但是就在要新增檔案的時候, 發生了跟 Lifetype 一樣的問題. 但是不同的是, WordPress 至少有 error message 出現, 說了 "Fail to write file to disk." 雖然還是不夠明確, 但至少我可以肯定是要寫入 file 到 disk 時發生問題, 而不是 Lifetype 本身在 upload 上的程式有甚麼問題. 後來我改成使用正常安裝的 Apache + MySQL + PHP 也是有一樣的問題, 倒是這兩個 Blog 系統用 XAMPP(WAMPP) 裝在 Windows 上都是正常的. (同樣的設定)

而直到剛剛, 在嘗試了快一天後終於找到解決的方法. 原來兇手是 PHP 的設定. 在 php.ini 內有 upload_tmp_dir 的設定 :

<br />; Temporary directory for HTTP uploaded files (will use <br />; system default if not specified).<br />; upload_tmp_dir =<br />upload_tmp_dir = /tmp/phpupload<br />
在原本的設定中是把 upload_tmp_dir 給註解掉的, 但是因為他後面說明會使用 system default, 因此我之前就認為沒有問題, 結果該 system default 顯然是個謎, 所以 LAMPP 在 run 時不知道經過 PHP 所上傳的檔案要暫時存在哪. Anyway, 結果就是在系統的 /tmp 內開了一個 phpupload 的 directory, 並且把權限設成 777 fully access, 同時記得更改 php,ini 如上, 重新起動 LAMPP 就 ok 了.

寫到這裡忽然想到, 之前我裝設 Joomla ! 時遇到要安裝 Component / Plug-in 時無法自 local 端上傳安裝 package 的問題, 八成也是同樣的原因導致的吧, 當時以為是 Joomla 1.5 RC 本身的問題, 加上可以從指定的 URL 安裝就沒追下去了, 明天再來確認是否同樣的問題 = =

雖然我的電腦上是裝了雙系統, 分別是 Mandriva 以及 Windows XP, 但是最近切換回 Windows XP 的次數越來越少了. 理由之一是 RMVB 檔在 Compiz-Fusion 開啟下, 使用 Realplayer 不能順利播放的問題, 最近透過改用 SMplayer 解決了. 理由是最近 Microsoft 的 Windows Ginuexxxx ( 忘記怎麼拼 ), 會不斷的跟我說我的 Windows XP 是盜版 ( 明明就是學校買的校園授權版 ), 讓我很不想切換回去.

然後我最近又開始倚賴 VirtualBox 上的 Windows XP 來幫我處理其他在實驗室的必要需求. 像是 :

• 透過 Vigor 網路電視看轉播 : 使用 VirtualBox 完全沒問題, 順得很
• 簡單的編輯排版調整 : 在 VirtualBox 的 Windows XP 內灌好 Office 2003 以及 OpenOffice.org, 當需要把文件寄給 Windows 平台的使用者時, 作個簡單的排版調整就好了.
• 轉換字幕檔 : 有時候需要把非 Unicode 編碼的簡體電影字幕檔轉換成 Unicode 編碼, 這個目前我還找不到 Linux Desktop 下的替代方案, OpenOffice.org 以及其他編輯器開啟非 Unicode 編碼的簡體電影字幕檔往往都會是亂碼, 必須使用 Word 幫忙.

想了想主要好像就是這些而已. 不過在 Windows 稱霸的世界當然沒這麼簡單的事情. 因為研究以及計畫需要, 有些 software 就是非得在 Windows 上跑不可(他就只有 Windows 版阿), 或是必須在 Windows 上進行測試才能發現問題, 像是我前幾天遇到的 wxPython 問題. 這樣要在主系統與 VirtualBox 上的 application softwares 之間進行 data 的交換其實是很麻煩的事情, 同時這些 software 的 collaboration 往往必須透過使用者的介入.

是否針對此類的問題, 我們可以把 VirtualBox 變為一個 Middleware, 來處理兩個 platforms 上的 application softwares 之合作呢 ?

舉 data exchange 來說, VirtualBox 本身會佔用硬碟的一部分空間, 如果把該空間視為 VirtualBox 可以管理的 resources, 然後定義一組 interface 給主系統使用, 另外一組 interface 給 Windows XP 上的 application 使用. 而這兩組 interface 可使用, 透過 VirtualBox 就建立一個 communication channel, 可以 real-time 進行 data exchange, 甚至在 VirtualBox 的幫助下, 可以直接對彼此下 commands.

對於主系統來說, 其實相當於透過 network 與另外一台運作著 Windows XP 的系統進行 communication 並要求 service, 只是透過 VirtualBox, 可以在一台 PC 上直接達成. 甚至當 VirtualBox 同時運作多個系統時, 不同系統上的 applications 之間可以直接進行同樣的 communication.

相對於 Web-based Collaboration, 暫時把這樣的想法稱為 VM-based Collaboration 吧.

今天因為 project 的原因, 想裝起 Joomla ! 來試試看. 但是 Joomla ! 的網站上好像暫時停止 download 以及 demo film 的下載, 原因不明. 想說好吧, 不然就用 Mandriva 內建的 Joomla packages 裝好了. 結果剛勾選完, 驚訝的發現居然相關的需安裝 packages 包含 Joomla 總共高達 36 個 @@


雖然說裡面包含了 Apache 跟 PHP 相關的 packages, 但是重點是我之前系統中並不需要安裝這些, 這些是由於 Joomla ! 的需要才有相依性安裝的.

藉著這個機會剛好想嘗試一下很久以前就發現的問題 : Package Manager 好像都沒在紀錄 package installation dependency 的, 因此想移除某 software 時也一併移除之前因為相關性才裝的 software, 好像無法透過 package manager 的幫助達成.

所以裝完 Joomla ! 後, 又故意把他移除試試看. 果然, Mandriva 內建的 package manager (RPMDrake) 只會偵測到 Joomla ! 相關的兩個 packages.


而在移除過後, 再度選擇裝回去, 就會發現現在只需要裝兩個 packages 了. ( 就是剛剛移除的 Joomla ! 相關 packages. )


這個結果意味著, 在 Joomla ! 被安裝時, 因為相依幸而被安裝的其他 packages ( Package In ), 在 Joomla ! 要被移除時 ( Package Out ), 並不會自動地被移除, 或是詢問使用者是否要一併移除. 然後就這樣留在系統中, 成為不知哪時才會被用到或是被更新的 useless packages ( Packages Left Behind ).

事實上要紀錄 package 被安裝時的 dependency associations 應該不是難事, 甚至當你要移除某個 packages 時, package manager 也會提醒你此 package 目前被哪些 packages 所依賴, 如果移除可能會出現問題. 顯見這些 dependency 資訊應該已經有被紀錄起來, 為何在 remove package 時, 卻不提醒使用者一併移除可能之後不會用到的 packages 呢 ?

我能想到的主要原因只有一個. 因為整個系統嚴格上來說並不受 package manager 管轄, 所以當面臨移除的指令時, package manager 並無從知道是否之前因為 dependency 而安裝的其他 softwares, 在 package manager 管轄之外, 被其他經由使用者自行安裝的 packages 所利用, 這樣的 dependency association 目前是無法經由 package manager 所紀錄的. 因此 package manager 無法在殘缺的 dependency association information 底下, 確保 package 的移除不會出現問題.

然而不用 package manager, 靠管理者更難做到上述的 package dependency analysis. 是否有更好的方法, 可以 statically or dynamically 對於整個 system 內的 package dependency 作分析, 進而蒐集相關資訊, 使得管理者可以在 remove package 時, 很清楚的知道應該把哪些 packages 也一定移除嗎 ?

雖然努力了一個小時還是沒有成功, 但是還是紀錄一下好了.

因為找不到現成的 package, 所以就打算自己處理, 參考了一些網頁的經驗分享, 首先利用

./configure --enable-plugin

進行 configuration, 產生 makefile. 這裡遇到錯誤的話就裝上該裝的東西, 需要 gtk+ >= 2.4.0, 記得要裝 libgtk+2.0_0 package. 另外記得 libmozilla-firefox package 也需要裝.

而後進行 make 時可能會在進行 po/Makefile 時遇到這樣的錯誤 :

.po.gmo:
file=`echo $* | sed 's,.*/,,'`.gmo \
&& rm -f $$file && $(GMSGFMT) -o $$file $<
command not found

這是由於 GMSGFMT 參數變成了空白, 所以 command 在執行時變成了 -o, 所以系統無法辨認. 而 GMSGFMT 空白的原因是少裝了 GNU gettext package, 裝上去就 ok 了.

繼續進行 make 可能會遇到這樣的錯誤訊息 :

Making all in src
make[3]: Entering directory `/home/scsi/tmp/pcmanx-pure-gtk2-0.2.6/plugin/src'
make[3]: *** No rule to make target `pcmanx_interface.idl', needed by `pcmanx_interface.h'. Stop.

這在摩托學園有詳細的討論, 不過這已經是 2005 的討論了, 為什麼我現在還是遇到一樣的問題呢 ? 照著 jserv 的建議, 不過看了看 Makefile.am , 還是不知道怎樣產生 pcmanx_interface.h 檔案, 加上有討論說到 pcmanx_interface.idl在包裝中是缺少的...well, 搞不清楚情況下我的 make 嘗試就到此為止了.

剛好這時候資料找著找著, 看到了 DreamerC's Backyard 有提供修正遺失檔案的 package 下載, 就直接拿來用了. 這個 package 就沒問題了, 可以順利進行 make. 而在 make install 後, 相關的檔案就會自動部屬到該在的地方. 但是 Mandriva 2008 上預設的 firefox 安裝跟一般的不同, 結果 make install 是把相關的 components 安裝到 libmozilla-firefox 裡面了.

不知道這樣的部屬 (deployment) 是否正確, 不過總之最後雖然部屬了, 還是沒辦法在 FireFox 中順利啟用 PCManX. 之後參考大步向前走的手動部屬提示, 做了檢查以及更動嘗試, 還是沒辦法進行. 只好先記下上面的東西摟, 之後有空再繼續 try 吧.

至少 make 後單機版可以用倒是沒問題.

在我涉入 Software GUI 的研究領域之初, 我所思考的第一個問題其實是跟 Software User Interface Copy 有關的問題. 當時的觀察對象是 XMMS 跟 Winamp, 以及其他在 Desktop Linux 上跟已經在 Windows 上存在已久的 softwares 之間極為相似的 GUI 設計. 當時的想法是希望探討 GUI 的設計模仿跟 OSS 的成功之間是否存在關係, 以及是否 OSS 可以在發展初期藉由模仿既有的 popular software GUI 設計, 取得較大的成功優勢. 當然這背後還牽涉到怎樣把 functionality 跟 non-functionality 的 GUI 連結起來並從整個 global software 身上分離的問題, 這在目前也還沒有具體的研究成果. 不過這個想法最終是死在對於智慧財產權的考量. 因此雖然我還是在嘗試解決相關的問題, 但是採用的是完全不同的做法.

這幾天看到一個有趣的 Desktop Linux Distro. : Vixta Linux. (以下 screenshots 取自 Vixta@S.F.net)

Vixta 是以 Fedora 8 為基礎作修改的 Desktop Linux Distro. , 從名稱以及外觀不難看出來是 follow Windows Vista 的 style. 雖然模仿 Windows style 這不是第一樁, 但是在隨著 EeePC 使得 Linux 能見度再度提高的同時, 出現了跟 Windows Vista 極為相似的 Linux Desktop, 還是比起之前對於 Windows 2k, XP 的模仿更具意義. 而即便是在一些操作的介面上, 例如 File Manager, 也弄得很接近 Windows 傳統的方式. (不過其實原本 Konqueror 的 side bar 比較 powerful)

這樣的模仿, 目的之一當然是希望能夠混淆視聽, 讓使用者分不出來這是 Linux 還是 Windows Vista, 以達到想要的結果, 也就是寫在 Vixta Goals 裡的 : Spread linux to the "masses", User-Friendly, 以及 Familiar look and Feel.

假設 Vixta 可以達到他想要的效果好了, 這意味著使用者無法在使用 Vixta 時分清楚究竟現在他用的是 Linux 系統還是 Windows 系統, 要達到這個程度, 不是只改改 layout 介面就可以作到的. Software GUI 的真正意涵在於連接 Software 的運作邏輯 (Software Implementation Model) 與 User 的使用邏輯 (User's Conceptual Model) [1][2], 而通常後者的可變動性 (flexibility) 是比較大的, 因此可以說 Software GUI 是決定了怎樣把 Software 的運作邏輯表現給 User, 使得 User 可以在最小修正使用邏輯的前提下, 最有效率地利用該 Software. 而如果今天出現了一個 Software GUI, 可以讓 User 察覺不到背後的系統更換, 那麼被更換的兩個系統, 與 Software GUI 之間必定有相當程度的 decoupling -- 換句話說, 在 Software GUI 與背後的系統之間有相當清楚的 Interface 存在.

D. Collins 在 [1] 中引用了 J. Bennett 的 model [3][4], 訴說 User Interface 中四個不同的主要部分 : (the figure bellow is referenced form [1] )

圖中的 Implementation Model 是同時包含了 hardware 以及 software 的部分. 可以看的出來各部分之間的 coupling 關係, 使得要完成一個完整的 Software User Interface Copy 是很難的事情, 因為多多少少不同的系統在 Implementation Model 上都有差異, 也會影響到 Presentation Language 以及 Action Language 的呈現. 如果為了 Copy 而去改變 Implementation Model 就有點本末倒置了. 我相信 Vixta 總不會為了要讓 User Interface 更像 Vista 一點而去改 Linux 系統本身吧.

但是這是不是意味著 Software User Interface Separation (from Functional Application Part) 是不可能的呢 ? 我覺得倒也未必, 只是可能不會由目前的模仿之路作到, 而是透過 UI Design Patterns 的路作到. 重點還是在於 User 是否需要這樣的東西.

即便在 Windows 上也是有許多嘗試改變 Windows 預設 User Interface 的 softwares 存在, 例如比較有名的可能是仿 Mac 的 FlyakiteOSX, (figure bellow is referred from Screeshots@FlyakiteOSX)

這下好了, 用 Linux 的人在用 Windows 的 Desktop, 用 Windows 的人改用 Mac 的 Desktop, 下一個會是誰用誰的呢 ? 但是可以肯定的是, 只要 User 有這樣需求的一天, User Interface Separation 的可能性就一直存在, 差別可能只在於會在哪出現, 是在 OS 上, 還是會率先在 Web Applications 上出現呢 ?


References
[1] Dave Collins, Designing Object-Oriented User Interfaces, Addison-Wesley, 1995
[2] Theo Mandel, The Elements of User Interface Design, Wiley, 1997.
[3] John Bennett, "User-Oriented Graphics Systems for Decision Support in Unstructured Tasks," ACM SIGGRAPH, 1977
[4] John Bennett, "Analysis and Design of the User Interface for Decision Support Systems," In Building Decision Support Systems, Addison-Wesley, 1983

其實我只是想換個 theme 罷了.

基本上我這個人對於 Desktop Operating System 越來越沒有特定的信仰. 以前無知時只用 Windows, 後來還是有點無知時只用 Desktop Linux, 再後來雖然還是蠻無知的, 不過變成了看心情跟需要, 一陣子用 Windows, 一陣子就改用 Desktop Linux. 昨天剛剛換成了 Mandriva 2008, 好一陣子沒用, 之前是用 Ubuntu. 但是可能因為 KDE 版本有差, 之前沿用的 theme 讓 menu bar 出現了問題, 所有的 icons 跟 quick links 都不見了, 變成空白一條. 弄了幾下調不回來, 索性整個 KDE 相關的設定都重來吧, 反正只是調整幾個地方.

上 KDE-look 找了個看起來不錯的 theme : Domino style engine, 想說裝裝看, 結果到我可以 make 為止, 總共遇到了以下的問題 :

1. 缺少 C++ Preprocessor
   
2. 缺少 libX11 development package
   
3. 缺少 libxext
4. 缺少 libz
5. 缺少 Qt-devel
6. 缺少 KDE headers
   

第一個 C++ preprocessor 的問題是因為沒有裝 gcc-c++ package, 所以出現了這樣的訊息 :

configure: error: C++ preprocessor "/lib/cpp" fails sanity check

在Mandriva 2008 中, 根據 package manager 的分類, 利用 gcc 關鍵字可以查到的有四個主要的 packages, gcc, gcc-c++, gcc-cpp, gcc-gfortan, libgcc1. 如果只知道要裝 gcc 是不夠的, 因為這裡的 gcc 是指 GNU Compiler Collection, 包含的是 GNU 的各個 compilers 會需要的基本元件, 而各種 programming languages 的 compiler 在架構上是分開的, 也就是還需要裝 gcc-c++ 在這裡才能夠符合需要.

第四個問題的訊息是這樣的 :

checking for libz... configure: error: not found.
Possibly configure picks up an outdated version
installed by XFree86. Remove it from your system.

這個 libz 又是甚麼呢 ? 而且他的提示訊息居然還建議我移除可能的安裝 !? 查了許久才確定應該是 libz.so.1 這個 library, 隸屬於 zlib package, 而且他需要的是 zlib-devel package.

我不想討論這些 installation burden 跟 risks 的問題, 這已經被討論到爛了, 從六年前 Desktop Linux 看起來開始可以讓一般使用者接受時, 到現在一直還是存在這問題.

基本上我覺得這是短時間不可能消失的問題, 應該要被討論的是, 誰應該對這個問題負責任 ? Who Should be Responsible for the Installation Burden and Risks ?

是使用者自己嗎 ? 這樣 Desktop Linux 又變為只有 hacker 可以用的系統. 使用者說, 我只是想換個 theme 阿, 為什麼看起來不相干的準備工作這麼多, 這些動作到底在做甚麼, 為什麼這些不是給我 software 的 developer 處理好.

是 software developer 嗎 ? developer 會說, 我哪管得了那麼多, 那根本是在我的 software 之外阿, 我哪知道不同的 distro. 會預設哪些 library, 哪有美國時間每個 distro. 都去測試, 況且沒幾天就有一個新的 distro. 誕生. 這問題還是丟給 distro. 公司以及 community 解決吧.

是 Desktop Linux distro. 嗎 ? 製作 Linux distro. 的公司說, 奇怪了, 使用者又要可以選擇自由安裝的 flexibility, 又抱怨不知道該裝哪些, 我對於每個 package 的說明不是都寫的很清楚了, 我怎麼可能知道使用者會裝哪些我預期外的 software, 又怎麼可能幫該 software 決定要抓哪些 library 來裝, 這是 developer 的事情阿.

當大家都把責任往外推的時候, 其實就是建立標準的時候了. 這不是個不能解決的問題, 只是沒有任何一方想要擔負這個責任, 因為很麻煩. 之所以麻煩就是因為缺乏標準. 如果可以有一個標準讓所有人去遵循, 結果可能就會出現像 UPnP 的東西, 大家遵照該標準做事就 OK 了.

附帶一提, 結果我還是沒辦法把該 theme 裝起來, 因為 make 後還是出現了看不懂的 compilation error, 這又要誰來解決 ?

lazybuntu [1] 是國內著名 bbs/web browser 軟體 PCMan 的作者(也叫 PCMan :p)發起的計畫, 就如同其他 lazyxxx 計畫一樣, 是希望透過把常用的, 好用的 softwares 綑綁在一起(software bundle), 並設定好在特定 platform 上的安裝設定以及 package deployment, 使得在該 platform 上的使用者可以快速地安裝好必要的 softwares. 當然會這樣作的原因也包含了在原來的 distributions 中並未能夠考慮特定區域的使用習慣來決定內建的 packages 支援, 或是因為 packages 太多反而讓一般使用者不知道怎樣選取.

相似的東西, 最近國內比較 hot 的應該是 lazyeeepc [2] 吧, 而我之前為了求方便分別在 Linux 以及 Windows 上也使用過的 XAMPP [3] 也算是類似的東西. 但是我認為從 information & knowledge engineering 的角度來看, 這些 software bundles 之間還是有所不同.

如果只是從 把常用受歡迎的 softwares 一起包裝起來 的角度來看 software bundle, 那麼 software bundle 其實可以被看為是一個 packaged information aggregation. 在此 aggregation 內, softwares 是以特定的關係被 connect 在一起, 但是這樣的關係只會是 在同樣 platform 上的關係, 或是跟某個 programming language 相關等等的關係, 並沒有包含這些 information 怎樣以有方向性的關係作連結的資訊.

以 XAMPP 的例子來說, 有意識地選用了特定的 software 組合, 意味著完成 XAMPP 的 developer 認為這樣的組合在他的使用經驗中具有某種優勢, 這樣的組合是對於他來說是有意義的. 而有意義意味著對於 Information 的認知能夠提供他使用上的某種經驗, 於是 Information with Meaning 就變成了 Knowledge.

更甚而可以形成某種解決問題的 pattern, 擁有合適的 context description, 以及使用此 software bundle 時需要考慮的 forces, 使用後的 consequences 等等, 這就已經不再只是 information aggregation 的 level, 而是把 software bundle 作為一種 knowledge sharing 的手段了.

以 lazybuntu 來說, 其實蠻有淺力往這邊走的, Ubuntu 的使用者多, 在 Ubuntu 上的 applications 也多是兩個主要的原因. 但是要以怎樣的 format 讓 contributers 可以在 lazybuntu 上分享自己的 "knowledge" 倒是一個難題. 特別是所謂的 knowledge 是可以包含各種使用方式的, 像是 Apache 雖然是 web server, 但是我也曾經把他跟 Trac 綁在一起用, 原因只是為了利用 Apache 的密碼加密模組.

當我們可以把 software bundle 完完全全視為一個被 share 的 knowledge 時, 或許到時看到的就不再是 software 的 composition (或說是 component composition), 而是現在正開始熱的 service-orientation 的角度了. 到時我們看的不是一個一個的 softwares, 而是看到 softwares 經過適當的組合, 經過使用的測試, 匯集使用的經驗, 所提供出的 services.


References

[1] lazybuntu, URL : http://lazybuntu.openfoundry.org/
[2] lazyeeepc, URL : http://yurinfore.blogspot.com/2007/10/lazyeeepc-001.html
[3] XAMPP, URL : http://www.apachefriends.org/zh_tw/xampp.html
[4] Michael Negnevitsky, Artificial Intelligence : A Guide to Intelligent Systems, Addison-Wesley, 2001