GNU 正式發表 Eamcs 22.1

在停留在21 版六年之後，gnu 終於正式發表了22版。官方宣告在此
http://permalink.gmane.org/gmane.emacs.announce/11

一些主要的新增功能有
支援GTK+ 介面
X windows Drag-and-drop
支援 x86-64 架構
...
基本上族繁不以備載。

個人試用結果:我在Mandriva 2007.0上已開始用了 emacs-gtk beta版的RPM ，感覺相當不錯，unicode直接支援，不用加裝套件。
2007.1 開始， 舊版emacs-21.4-2跟emacs-snapshot-common-22.0.94-1跟xemacs-21.4.19-4 三者可以共存

OpenOffice.org Mac OS X aqua 版現身

朋友借我臺舊Mac 幫他出問題時看看。以後開始會留神 Mac上的開放原碼軟體

MacOS 的使用者大多是用 NeoOffice 去讀寫 openoffice
聽說以往在Mac上裝 openoffice 需要加裝 X-windows
照這樣推斷，Mac OS 的aqua 介面不是基於 X-windows 的東西，這倒是出乎我意料之外
竟然基於 BSD 核心的圖形化系統沒有跑 X-windows !

今天 Openoffice.org 宣布了Mac OS X aqua版官方的OpenOffice.org (叫作 OpenOffice.org Aqua) Alpha 版開放下載
需要 Mac OS X 10.4 (Tiger)
http://porting.openoffice.org/mac/download/aqua.html

Alpha 版意味這是不穩定的測試版，
不過這對開放格式ODF 的版圖擴張有某種程度的正面意義

詳情見
http://porting.openoffice.org/mac/download/aqua.html

skype linux 1.4 終於現身

基本上相對於其他完全開放/半開放(只開放client端)原碼的VOIP如gizmo，我不是很喜歡用skpe 。純粹是為了在Linux 上保有跟其他平台的人通話的使用自由，才在用被迫用skype。相對於其他Linux上的VOIP軟體，skype 的Linux 1.3 版作的不好，跟skype自己 windows 版穩定度，功能...，也差上一大節。Linux版大半年沒改版了，還是蠻期待基本的音效穩定度可以加強。

現在1.4 還在 alpha 階段。改進了不少東西，audio裝置的選擇變多了，而且開始有支援API/dbus 。使用介面用最新的QT4 改寫過了
不過介面的分群暫時無法顯示，看來怪怪的。有些功能像OSS 支援暫時拿掉了。不過不礙事。

有分兩個版本:
skype-alpha_staticQT-1.4.0.64-generic.tar.bz2
需要 libdbus-1.so.2 可是Mnadriva 2007 64bit 系統裡的是 libdbus-1.so.3，所以要
cd /lib; ln -s libdbus-1.so.3 libdbus-1.so.2

需要 32bit libsigc++2.0 所以要手動安裝
urpmi libsigc++2.0_0-2.0.17-1mdv2007.1.i586.rpm

假如是skype-alpha-1.4.0.64-generic.tar.bz2 (for static release) 還要多裝 32 bit libqtdbus4
urpmi libqtdbus4-4.2.3-3mdv2007.1.i586.rpm

並且把在 /lib 建立對應的 symbolic link
cd /lib;
ln -s /usr/lib/qt4/lib/libQtGui.so.4 libQtGui.so.4
ln -s /usr/lib/qt4/lib/libQtNetwork.so.4 libQtNetwork.so.4
ln -s /usr/lib/qt4/lib//libQtCore.so.4 /libQtCore.so.4
ln -s /usr/lib/qt4/lib//libQtCore.so.4 libQtCore.so.4

不過 skype 官方說
* Qt 4.2.3 contains a bug that if unpatched will cause expanded contact details to be displayed incorrectly.
* Qt 4.3.0-beta is considered not yet release worthy, and may cause unpredictable side-effects with the Skype 1.4 client.

所以我還是改用靜態連結版本。

詳細參見
https://developer.skype.com/LinuxSkype#head-3fc9435082cb4f65fac2d0cc058d4265ccceb7d7

Mandriva 2007.x 3D desktop 啟動速度比較

Mandriva 2007.x用了 parallel init，開機真的不慢，到gdm/kdm 這段都算快
用了雙螢幕好久一段時間，但2007.0 開機+desktop啟動速度感覺上是用過最慢的一個。即使CPU 一直在提升(現在是AMD 4000+, 1M L2 cache), video 保持在nvidia Ti-4200 128M RAM
不知是雙螢幕，compiz，2007.0，還是我沒設好？試過CPU 3000+/4000+差距不成問題。但換成2007.1新的組合就沒事了，又回到以前那種啟動神速。所以我認為是 2007.0 系統設定/xgl/舊版nividia 驅動的問題。

我反覆測試的結果，發現就算同樣的設定，數值也有數秒(n<5))的波動，也許是parallel init/硬碟cache hit 所照成的，留幾個數據供大家參考:

舊的2007.0(nvidia 96xx twinview + gxl +compiz + gnome 2.16)
1. 從 grub 按 enter 開始到圖形介面progress光條完成: 33 sec
2. GDM 出現 再加7 sec (中間有出現 nivida logo畫面，可以在xorg.conf裡把他拿掉 )
3. 從GDM 打完密碼到compiz 把 gnome menu(包含網路的服務)全部load 完
再加2分24 sec
0:33+0:07+2:24=3:04

其中第三段:
gdm 打入密碼後螢幕變黑，中央出現gnome 2.16 載入中的小視窗
視窗裡有幾個icon ，全載入後才會進入gnome 桌面(開始載入桌布/選單之類的。)光是gnome 2.16 載入中的小視窗第一個icon 出現，就在那裡停了2:21所以我的menu 服務icon雖多，一共也才幾秒 (2:24-2:21=0:03)這幾秒內可以看得到網路服務icon先畫出沒資料，再畫出網路資料，瓶頸不在畫menu那。雖然我的menu 很多，光包含網路的服務(天氣)就好幾秒，但gnome desktop 完成絕對要2分多，大瓶頸

新的2007.1 (nvidia 96xx twinview + aigxl +compiz + gnome 2.18)
1. 從 grub 按 enter 開始到圖形介面progress光條完成: 35 sec
2. GDM 出現 再加12 sec (中間有出現 nivida logo畫面，可以在xorg.conf裡把他拿掉 )
3.1 從GDM 打完密碼到螢幕變黑，中央出現gnome 2.18 載入中的小視窗完成消失: 再加4 sec
3.2 gnome 2.18 載入中的小視窗完成消失: 再加10 sec
3.3 gnome 桌面全部載入(桌布/選單之類跟畫出額外的網路服務icon跟網路資料 )再加11 sec(假如螢幕都很乾淨，沒有放大量的捷徑的話，則只加 4sec)
2007.1 起動桌面的時間
0:35+0:12+0:04+0:10+0:11=1:12
對照2007.0的 0:33+0:07+2:24=3:04快了一倍

我沒力氣去追glx 的問題。我之前遇到一些與舊程式不相容的情況。如nvidia-settings 不會正確顯示的問題，讓我 決定放棄glx。一度我想裝beryl 來取代 compiz 但是不管2007.0/2007.1 ，nividia 或ATI 上全裝不出來，還把gnome 給搞砸了。雖然beryl 有一些外掛如火燄特效很酷，不過至少在compiz 上，最重要的視窗縮圖預覽(MacOS X 上的 expose') 功能，aiglx 跟xgl 速度差異根本感覺不出來。所以決定先用 aiglx 的 compiz 來工作。

另外 2007.1 只跑單螢幕+沒 3D 桌面的情況:
第1, 2段也是約 40 sec (36+9=45)
第三段: (10+8)=18 sec

關於雙螢幕3D 桌面的設定，則會再另外刊出

"不負責"自由軟體中文輸入法改進規劃:

下面是我目前比較關心的: (我之前還列出重覆輸出，後來不知道怎樣了。)

1. 列出同音字待選
2. 編打編唸 (用語音確認)
3. 放大輸入緩衝區 (這樣user 可以少按幾次輸出鍵)

第一個 在我提出feature request 後, gcin 的作者已經實作出來了，太帥了。新酷音好像還沒看到。
第二個 工程浩大，但我一直有在設法集合各方力量去實作，包括結合圖書館界想要作無障礙閱讀環境的資源。除了基本的收集標準語音外(402 個基本音，加上四聲變化，會少於 400x5=2000個音)，
在Linux 上，還需要聯接Alsa API，我覺得最好能支援用Jack IT ，因為怕多工環境下延遲
第三個 其實我沒很大把握，因為我還沒從頭到尾trace 過gcin 跟新酷音的原碼，不瞭解取詞的演算法 ....先當我是小白好了，所以這篇取名"不負責"...規劃。已經做好心裡準備被罵搞不清狀況，不過至少當豬頭拋磚引玉，應該比光要人改進，但連實作規畫都沒有的來的強一點點。

想法從下面節錄新酷音兩位網友的討論引申出來，要在便利跟效率中取得平衡:
有沒有可能改成，把大的緩衝區分成兩部份，在M 字輸入緩衝區中(比如說 M=45)，只look ahead 最接近游標的 N (=15)字主緩衝區? N <=M 。一直輸入不後退超過了N 字的話，緩衝區前面(M-N) 字就暫時放到次緩衝區去 (移 link-list 的指標就好，其實沒有copy 資料的動作) 次緩衝區暫時不能改。假如使用者游標一直退到前 m-n 個字串範圍裡，主緩衝區跟次緩衝區會跟著變動，主緩衝區只look ahead 最接近游標的n 字

這樣只會constant-time slow : up to 2^N = 2^15 外加上 "雙緩衝區" (這我不知該如何解釋)的overhead， 應該是 linear time

能不能實做還是要看新酷音的原碼，其實不是不想，但以前就說了，沒有註解的C程式 我實在吃不消

---------------------------

windows_usr wrote:
> > 我用的是win32的最新win32-chewing-0.3.4.2.exe版本，說明裡寫著輸入一整句後按Enter,但我發現每輸入15個字就會
> > 自動送出超過此長度的字串。句子一般長度也有25-50個字吧，15個字真的太少了，打字時常常需要翻看，因為怕字自動送出了，沒有修改的機會，這樣很
> > 大地影響打字速度。酷音輸入法真的很好用，希望開發組可以加入自訂自動送出字串長度的功能。

Kuang-che Wu wrote:
> > On Thu, Apr 26, 2007 at 04:28:35AM -0700, windows_usr wrote:
>> >> 普通句子長度是25-35個字，加上夾雜一些英文。我想最好有45個字的buffer。
> >
> > 現在 libchewing 的運作原理, 當太長的話可能會很慢 (接近 2^n 的速度成長)
> >
> > 你可以試試看輸入
> >
> > 程式程式程式程式....
> >
> > 一整串, 越長會越慢, 在 input line 快滿那時, 速度已經慢到可以察覺.
> > 再更長的話, 可能就會慢到無法接受了