又遇到了詐騙電話(錄音)
詐騙過程的資訊已經送到了 http://165.gov.tw/case_tell.aspx (感謝 sjh 提供 
)
補上一個錄音檔案 ^^
Updates from 三月, 2010 Toggle Comment Threads | Keyboard Shortcuts
-
kiang
-
kiang
我遇到了好人，遇到了壞人
我遇到了好人，在生活中遇到了突發的狀況，經由朋友的介紹，我們獲得了一些專業的朋友協助。在討論問題的過程中，我們也相當相信他們的專業，因此把問題托付給他們。因為他們是好人，所以我們對他們的決定沒有太多懷疑，儘管關切的親友有提到一些疑問，我們都為他們找到理由、藉口回應，讓關切的親友也相信他們是好人。也許是他們在忙、他們應該有專業的考量、我們應該相信他們，因為他們是好人，我們沒有太多的懷疑，狀況處理的過程都照著他們的指示進行，也順利了度過了第一個難關。
悲劇總是接連發生的意外所造成，第一個難關之後延伸了更棘手的第二關，因為他們是好人，我們還是請他們協助，也儘可能的提供我們所能夠提供的資訊。因為他們是好人，有很多人相信他們，所以他們變得很忙，第二關儘管比較棘手，他們也有些力不從心，因為我們相信他們是好人，所以他們也繼續當好人，只是過程中沒辦法提供更多的協助，儘管我們提到希望投入更多的資源來取得他們更多的協助，他們並沒有接受，因為他們是好人，他們也相信能夠以有限的資源進行處理，我們也相信他們，然後他們繼續當我們的好人。
悲劇的意思就是沒有歡喜的結果，我們在第二關慘遭滑鐵盧，發現很大的原因是他們在協助第一關時留下了隱憂，而這樣的隱憂在第二關變成了致命的關鍵，我們事後才知道這個隱憂的存在，而這個隱憂如果當初沒有急著在第一關畫下句點，我們也許可以有充份的討論來避開它，當時我們佔盡優勢。因為他們是好人，我們在處理過程中忽略了應該有的警戒心，因此需要面對嚴重的後果。我們還是相信他們是好人，但是對於這樣的後果我們無法自行承擔，因此在長時間的討論後，我們決定要求他們分擔其中的損失，但這時候他們也抗議了，抗議我們沒有交代清楚資訊、抗議我們別有居心、抗議我們相信他們是好人。很遺憾的，那些說是沒有交代的資訊，我們在口頭提到時沒有錄音記錄，但我們確實有提過，因為我們是第一次面對這樣的問題，深怕有任何不測，所以過程的任何細節我們都有深刻的印象，我們也沒有能力去思考其他的意圖。
遇到好人還是會面對這樣的結果，最悲哀的是，我們需要跟好人在爭辯的過程中承擔這個後果，那個壞人繼續耀武揚威。
我遇到了壞人，因為在第一關時他們不願意積極處理問題，讓我們需要求助於好人。因為他們是壞人，在第一關有明顯的缺失存在，但是他們一直不承認自己有錯，甚至找了其他的壞人編織故事想要讓我們耽誤問題處理的時間。因為他們是壞人，我們不相信他們，所以有看出他們的意圖以及注意到問題的時效性，我們及時找到了好人幫忙處理，壞人自然就被打敗了。
因為他們是壞人，第二關也是拒絕配合，而且還更進一步的透過各種方式進行騷擾。因為他們是壞人，所以各種騷擾都遊走在法律的邊緣，簡訊、電話或是到住家叫囂，即使請警方協助處理，警方也表示莫可耐何，我們只能繼續提防他們這些壞人。第二關一度是我們佔上風時，壞人情緒化的程度加深，開始有了超過法律邊緣的舉動，可惜沒有來的及進行蒐證，所以他們還是可以繼續當幸運的壞人。
最後，第二關我們輸了，他們竟然還是繼續騷擾。因為騷擾的過程警察也幫不上忙，於是我們將這個過程寄給壞人的父親，請他轉達不要再做這種傻事。壞人在得知後反而變本加厲，這時候我們已經準備好各種蒐證工具，他們也的確踰越了法律的界線，我們將所有的資料送交警方處理，希望給他們一些警惕。因為他們是壞人，我們在處理時可以保持警覺，可以毫不猶豫的透過各種方式懲罰他們。
生命的過程似乎總會遇到些好人、壞人，但有時候換個角度看，好人不一定好、壞人不一定壞，投入過多的情感會讓好與壞之間失去界線，但是沒有情感好像也不像個人。儘管人生充滿矛盾，我們還是得繼續走下去。下一關我們得面對好人跟壞人，祝福我們吧。
-
kiang
激情過後，在下一個莫拉克來臨前
莫拉克颱風於 2009年8月7日於23時50分由台灣花蓮縣登陸，8月8日14時由桃園縣出海，是台灣氣象史上傷亡最慘重的侵台颱風。這次風災也或許是資訊最混亂的一次，或該說是資訊技術參與救災最廣的一次，因為陸續有多個自願者架設了彙集資訊的網站，主要是讓受災民眾可以透過網路發出求救的聲音，或是由網友提供各種相關資訊，顛覆了以往只能等待政府、媒體提供資訊的型態，而且參與人數以及程度都可說是空前。因為這些網站都沒有足夠的時間進行規劃，因此陸續出現了下面問題：1. 短時間內產生的資料量過大，網站無法負荷而頻頻當機2. 進入系統的資訊過多，剛開始時沒有組織人力進行即時的過濾與處理3. 發佈的災情資訊不易追蹤，導致救災資源的重置或浪費4. 有心人士利用系統進行各種非相關資訊的宣傳，或是試圖攻擊系統5. 缺乏政府相關單位的支援，導致部份資訊沒有獲得應有的重視6. 多個網站間資訊有重複、不同步的問題，讓資訊更難以掌控7. 過多的資訊引發恐慌、焦慮等心理影響8. 大部分的資訊都是匿名發佈，不容易辨識真偽接著開始有許多自發性的救災活動透過上述網站進行人員、資源募集，透過新聞媒體得知一些狀況發生：1. 志工未經妥善安排，導致與政府救災機制產生衝突2. 非營利組織之間資訊難以交流，導致受災民眾需要填寫大量的資料來確認受災身份，也有資源重置情形3. 各種救災物資送錯地方，有災民收到不需要的資源、有災民一直等不到資源4. 政府的注意力隨著媒體前進，許多媒體並未注意到的災區政府缺乏即時的因應機制5. 開始有投機性的災民或是一般民眾利用錯誤的資訊來圖利自己在災害慢慢趨緩後，似乎也沒看到對這些資訊的整理、統計、分析工作進行，畢竟下一個災害來臨前，我們需要這些經驗來進行災害的防治工作。今天上午有跟蕭博士碰面討論，他們打算以 Sahana 為基礎去延伸救災資訊所需工具。他提到，目前許多廠商積極爭取政府單位的救災系統建置計劃，只希望這些計劃未來能夠透過標準格式產出相關資訊，讓 Sahana 可以運用；而他們對 Sahana 這個系統的期望是能夠整合不同非營利組織的資訊，以及管理來自各種社交網站或個人發佈的訊息，最後與政府的系統進行資訊交換，讓救災工作能夠順利進行。不過 Sahana 目前的狀態並沒辦法立即滿足這些需求，需要爭取相關預算來進行在地化的調整。對 Sahana 還不是很熟悉，僅就少數的觀察歸納出3個需求：1. 能夠承載高流量的問題回報系統在災害發生當時，如果沒有影響到網路基礎建設，會有許多的資訊透過網路發出，這個系統的主要工作就是取得與過濾這些資訊，而且維持穩定運作。特別需要加強過濾功能，除了透過技術進行辨識外，也要保有外部志工參與人工過濾的機制，像是問題新增同時指派志工處理，處理過程持續更新、合併重複資料等等。2. 能夠管理災民、物資、志工的資源管理系統在救災團體進入到災區後，需要有這樣的資訊系統輔助相關工作進行，這個系統的訴求是完整性，像是下面幾個例子：[1]災民從登記、安頓、配發物資到脫離庇護的流程[2]物資從登記、運輸、倉儲、配發到物資使用的教育等等[3]志工從報名、集合、裝備配發、任務發派、心理輔導的安排到解散的流程[4]罹難者的登記、攝影、辨識到遺體的處置登記等3. 能夠將任務分派到手持式設備的資訊系統人的記性有限，隨時帶著電腦進行救災工作也是有些難度，因此將任務資訊濃縮後放入手持式系統有一定的方便性存在，甚至可以進一步做到任務異動、取消的通知，避免救災人力的浪費。上面提到的都是片面的想法，一定會有缺漏、錯誤的地方，目的只是希望拋磚引玉，讓更多人能夠協助促成這樣的救災資訊架構能夠成型，而且實際為需要的人們帶來幫助。最後是一些災情通報網站的現況：莫拉克颱風急資集散網 – http://lingtelli.org/savetaiwan2010/01/05 17:00 無法連結莫拉克災情資料表 – http://typhoon.oooo.tw/2010/01/05 17:00 持續營運中莫拉克颱風災情支援網 – http://disastertw.com/helps2010/01/05 17:00 已經不存在2010/01/05 17:00 在 1/4 有提供最新的捐款名冊莫拉克災情網路中心 – http://typhoon.adct.org.tw/2010/01/05 17:00 在 1:03 PM Oct 6th, 2009 後就沒有更新了莫拉克災情資訊平台 – http://morakot.yam.com/2010/01/05 17:00 在 2009-10-25 18:07 後就沒有更新了莫拉克颱風於 2009年8月7日於23時50分由台灣花蓮縣登陸，8月8日14時由桃園縣出海，是台灣氣象史上傷亡最慘重的侵台颱風。這次風災也或許是資訊最混亂的一次，或該說是資訊技術參與救災最廣的一次，因為陸續有多個自願者架設了彙集資訊的網站，主要是讓受災民眾可以透過網路發出求救的聲音，或是由網友提供各種相關資訊，顛覆了以往只能等待政府、媒體提供資訊的型態，而且參與人數以及程度都可說是空前。
因為這些網站都沒有足夠的時間進行規劃，因此陸續出現了下面問題：
1. 短時間內產生的資料量過大，網站無法負荷而頻頻當機
2. 進入系統的資訊過多，剛開始時沒有組織人力進行即時的過濾與處理
3. 發佈的災情資訊不易追蹤，導致救災資源的重置或浪費
4. 有心人士利用系統進行各種非相關資訊的宣傳，或是試圖攻擊系統
5. 缺乏政府相關單位的支援，導致部份資訊沒有獲得應有的重視
6. 多個網站間資訊有重複、不同步的問題，讓資訊更難以掌控
7. 過多的資訊引發恐慌、焦慮等心理影響
8. 大部分的資訊都是匿名發佈，不容易辨識真偽
接著開始有許多自發性的救災活動透過上述網站進行人員、資源募集，透過新聞媒體得知一些狀況發生：
1. 志工未經妥善安排，導致與政府救災機制產生衝突
2. 非營利組織之間資訊難以交流，導致受災民眾需要填寫大量的資料來確認受災身份，也有資源重置情形
3. 各種救災物資送錯地方，有災民收到不需要的資源、有災民一直等不到資源
4. 政府的注意力隨著媒體前進，許多媒體並未注意到的災區政府缺乏即時的因應機制
5. 開始有投機性的災民或是一般民眾利用錯誤的資訊來圖利自己
在災害慢慢趨緩後，似乎也沒看到對這些資訊的整理、統計、分析工作進行，畢竟下一個災害來臨前，我們需要這些經驗來進行災害的防治工作。
今天上午有跟蕭博士碰面討論，他們打算以 Sahana 為基礎去延伸救災資訊所需工具。他提到，目前許多廠商積極爭取政府單位的救災系統建置計劃，只希望這些計劃未來能夠透過標準格式產出相關資訊，讓 Sahana 可以運用；而他們對 Sahana 這個系統的期望是能夠整合不同非營利組織的資訊，以及管理來自各種社交網站或個人發佈的訊息，最後與政府的系統進行資訊交換，讓救災工作能夠順利進行。不過 Sahana 目前的狀態並沒辦法立即滿足這些需求，需要爭取相關預算來進行在地化的調整。
對 Sahana 還不是很熟悉，僅就少數的觀察歸納出3個需求：
1. 能夠承載高流量的問題回報系統
在災害發生當時，如果沒有影響到網路基礎建設，會有許多的資訊透過網路發出，這個系統的主要工作就是取得與過濾這些資訊，而且維持穩定運作。特別需要加強過濾功能，除了透過技術進行辨識外，也要保有外部志工參與人工過濾的機制，像是問題新增同時指派志工處理，處理過程持續更新、合併重複資料等等。
2. 能夠管理災民、物資、志工的資源管理系統
在救災團體進入到災區後，需要有這樣的資訊系統輔助相關工作進行，這個系統的訴求是完整性，像是下面幾個例子：
[1]災民從登記、安頓、配發物資到脫離庇護的流程
[2]物資從登記、運輸、倉儲、配發到物資使用的教育等等
[3]志工從報名、集合、裝備配發、任務發派、心理輔導的安排到解散的流程
[4]罹難者的登記、攝影、辨識到遺體的處置登記等
3. 能夠將任務分派到手持式設備的資訊系統
人的記性有限，隨時帶著電腦進行救災工作也是有些難度，因此將任務資訊濃縮後放入手持式系統有一定的方便性存在，甚至可以進一步做到任務異動、取消的通知，避免救災人力的浪費。
上面提到的都是片面的想法，一定會有缺漏、錯誤的地方，目的只是希望拋磚引玉，讓更多人能夠協助促成這樣的救災資訊架構能夠成型，而且實際為需要的人們帶來幫助。
最後是一些災情通報網站的現況：
莫拉克颱風急資集散網 – http://lingtelli.org/savetaiwan
2010/01/05 17:00 無法連結
莫拉克災情資料表 – http://typhoon.oooo.tw/
2010/01/05 17:00 持續營運中
莫拉克颱風災情支援網 – http://disastertw.com/helps
2010/01/05 17:00 已經不存在
高雄縣社會處災情公告 – http://www.sw.kscg.gov.tw/index.php?html=cal_show.php
2010/01/05 17:00 在 1/4 有提供最新的捐款名冊
莫拉克災情網路中心 – http://typhoon.adct.org.tw/
2010/01/05 17:00 在 1:03 PM Oct 6th, 2009 後就沒有更新了
莫拉克災情資訊平台 – http://morakot.yam.com/
2010/01/05 17:00 在 2009-10-25 18:07 後就沒有更新了
-
kiang
XOOPS 控告過去的專案負責人 Herko Coomans
不管怎麼說，這都是個難過的時刻，在一個組織、社群被迫要透過法律途徑對抗一個過去的負責人來找尋正義時。很不幸的，這是目前 XOOPS 社群與 Herko Coomans[1] 之間的現況，他是過去的專案負責人以及位於荷蘭的 『Stichting XOOPS』 基金會負責人。 XOOPS 透過荷蘭 Zwolle-Lelystad 地方法院對他提出訴訟，要求他返還屬於 XOOPS 社群的基金 (大約 15,000 歐元)，這筆基金目前在 『Stichting XOOPS』 基金會名下。 XOOPS 由 Dorhout Advocaten[2] 代表(社群聯署活動略過，有興趣可以參考原文[3])為什麼會走到這一步？1) Herko 在 August 2003 — March 2006 之間擔任專案負責人，在 2006/4/20 ，當時的專案負責人 Skalpa 提出質疑時，他同意辭去他的位置[4]。2) Herko Coomans 在擔任專案負責人時，於 2004 提議成立 XOOPS 基金會，原本要設置在美國，但 Herko 抱怨太難以及太貴(當然，這完全不正確)，他在取信於 XOOPS 社群後將它以 『Stichting XOOPS』 名義登記在荷蘭，也就是他居住的國家。在 April 22, 2006 ， Herko Coomans 同意 XOOPS 專案不太可能正式選出負責人，他也同意開發團隊推薦決策成員不會有任何問題，因此在章程中加入了這個推薦並且確保它的合理。他也了解決策團隊與社群可以決定他是否能夠繼續擔任 Stichting XOOPS 的負責人，而 Stichting XOOPS 也必須要向開發團隊與社群提供報告。3) Stichting XOOPS 發佈了 2005[5] 與 2006[6] 年報在 2007 年決策成員被換成了 Marc-André Lanciault (Marcan) 與 David Ledbury (davidl2)4) 在 2007 秋天，當社群開始要求 XOOPS 的財務報表，得到的都是 Herko 的空頭支票[7]，而我們所不知道的是 Marcan, David 與 Herko 開始策劃要對抗 XOOPS[8]，其中也包括了幾個月前霸佔了 XOOPS 伺服器的 James Morris[9]，當時是取得了來自 XOOPS 創始人 Onokazu 與主機商的協助才順利取回控制權。由於策劃對付 XOOPS, Marcan, David, 與 Herko 很明顯的違反了他們在身為 Stichting XOOPS 負責人所被托付的職責，這是相當充份的理由來將他們解職。當遭遇反抗[10]時， Marcan 表示因為興趣不合而選擇辭職[10]5) Marcan 在 December 2007 辭職後， David Ledbury 也接著在 January 2008 辭去決策團隊的身份，不過 Herko Coomans 拒絕辭職。6) 在 Spring 2008 ， Herko Coomans 出售 http://www.xoops.com 網址，並且將網址指向網域名稱銷售網站，要求的金額是 $5007) 在這之後， XOOPS 理事會[12] (當時是 Phppp, Mamba, Kris_fr, Runeher, Irmtfan) 表決一致通過，將 Herko Coomans 在 Stichting XOOPS 的決策者身份移除(略過關於理事會合法性的說明，有興趣可以參考原文[3])理事會在 August 26, 2008 發信[13]給 Herko 表示，他們的意見是 Herko 違反了被托付的職責，他們決定將 Herko 從 Stichting XOOPS 除名。理事會也同時聲名他不再能夠代表 XOOPS 進行任何財務決策，當時所有人仍然希望能夠和平解決來讓社群繼續走下去。
Herko Coomans 拒絕接受並且由他的律師做後續連繫，他的律師提出了下面解決方案：A) Stichting Xoops 將會無償將下面項目轉移給 Xoops Foundation 基金會：- http://www.xoops.com 這個網域名稱- 所有跟這個網域名稱以及 XOOPS 相關的品牌智慧財產權- 現有財務餘額，估計為 10,000 歐元B) 在這些權力移轉後， Stichting Xoops 必須要解散違反了上述任何一項協議， Herko 同意為個別協議的違反支付 5,000 歐元(摘譯)9) 根據 Herko 在討論[14]以及當時的財務資料[15]，基金會在 August 2007 應該還有大約 16,000 歐元，因此在 Stichting XOOPS 帳戶應該還有超過 15,000 歐元。只有交出 10,000 很明顯是有問題的，因此理事會僱用了律師進行協調，進一步取得了銀行帳戶餘額資訊，截至 Nov. 11,2008 的餘額是 13,485.25 歐元以及 $3,758 美金，美金帳戶接著被移轉到歐元帳戶中。理事會也在這之中得知，Herko 不想要讓人知道他運用了基金會的款項，以 4,000 歐元向他自己購買了 http://www.xoops.com 這個網域，所以基本上 Herko 決定了 Stichting XOOPS 將會支付這筆金額到他的口袋。這當然也是很清楚的利益衝突，理事會也清楚表示這是非法挪用，在 Stichting XOOPS 章程[16]第 6 項清楚提到：e. 管理團隊同意任何活動都不要求報酬，不過他們被賦與權力，在執行任務所衍生的費用可以獲得補償。Herko 在 September 2003 以 $18.95 採購了這個網域名稱，當時他是專案負責人，而當時 Mithrandir 在 June 23, 2005 的文章[17]可以看出他是代表 XOOPS 專案進行這項採購。David Ledbury 在同一天的文章也可以證實[18]。Herko 在 Nov. 22, 2008 以 4,000 歐元將網域名稱賣給 Stichting XOOPS ，這是在理事會通知他被從 Stichting XOOPS 除名之後，當時也告知他不再被允許代表 Stichting XOOPS 進行任何財務決策。因為它是當時唯一能夠存取 Stichting XOOPS 帳戶的人，他提取了 4,000 歐元給他自己，這被視為是非法挪用，因為他應該只能夠獲得 $18.95 。10) 理事會仍然希望和平解決，也已經提議只要他歸還這些款項，這些款項可以用來支付理事會的律師費用，以及他律師費用的一半，然後專案可以繼續前進。11) 很不幸的， Herko Coomans 拒絕了這個方案，因此唯一的方法就是進入法律程序不管怎麼說，這都是個難過的時刻，在一個組織、社群被迫要透過法律途徑對抗一個過去的負責人來找尋正義時。
很不幸的，這是目前 XOOPS 社群與 Herko Coomans[1] 之間的現況，他是過去的專案負責人以及位於荷蘭的 『Stichting XOOPS』 基金會負責人。 XOOPS 透過荷蘭 Zwolle-Lelystad 地方法院對他提出訴訟，要求他返還屬於 XOOPS 社群的基金 (大約 15,000 歐元)，這筆基金目前在 『Stichting XOOPS』 基金會名下。 XOOPS 由 Dorhout Advocaten[2] 代表
(社群聯署活動略過，有興趣可以參考原文[3])
為什麼會走到這一步？
1) Herko 在 August 2003 — March 2006 之間擔任專案負責人，在 2006/4/20 ，當時的專案負責人 Skalpa 提出質疑時，他同意辭去他的位置[4]。
2) Herko Coomans 在擔任專案負責人時，於 2004 提議成立 XOOPS 基金會，原本要設置在美國，但 Herko 抱怨太難以及太貴(當然，這完全不正確)，他在取信於 XOOPS 社群後將它以 『Stichting XOOPS』 名義登記在荷蘭，也就是他居住的國家。
在 April 22, 2006 ， Herko Coomans 同意 XOOPS 專案不太可能正式選出負責人，他也同意開發團隊推薦決策成員不會有任何問題，因此在章程中加入了這個推薦並且確保它的合理。他也了解決策團隊與社群可以決定他是否能夠繼續擔任 Stichting XOOPS 的負責人，而 Stichting XOOPS 也必須要向開發團隊與社群提供報告。
3) Stichting XOOPS 發佈了 2005[5] 與 2006[6] 年報
在 2007 年決策成員被換成了 Marc-André Lanciault (Marcan) 與 David Ledbury (davidl2)
4) 在 2007 秋天，當社群開始要求 XOOPS 的財務報表，得到的都是 Herko 的空頭支票[7]，而我們所不知道的是 Marcan, David 與 Herko 開始策劃要對抗 XOOPS[8]，其中也包括了幾個月前霸佔了 XOOPS 伺服器的 James Morris[9]，當時是取得了來自 XOOPS 創始人 Onokazu 與主機商的協助才順利取回控制權。由於策劃對付 XOOPS, Marcan, David, 與 Herko 很明顯的違反了他們在身為 Stichting XOOPS 負責人所被托付的職責，這是相當充份的理由來將他們解職。
當遭遇反抗[10]時， Marcan 表示因為興趣不合而選擇辭職[10]
5) Marcan 在 December 2007 辭職後， David Ledbury 也接著在 January 2008 辭去決策團隊的身份，不過 Herko Coomans 拒絕辭職。
6) 在 Spring 2008 ， Herko Coomans 出售 http://www.xoops.com 網址，並且將網址指向網域名稱銷售網站，要求的金額是 $500
7) 在這之後， XOOPS 理事會[12] (當時是 Phppp, Mamba, Kris_fr, Runeher, Irmtfan) 表決一致通過，將 Herko Coomans 在 Stichting XOOPS 的決策者身份移除
(略過關於理事會合法性的說明，有興趣可以參考原文[3])
理事會在 August 26, 2008 發信[13]給 Herko 表示，他們的意見是 Herko 違反了被托付的職責，
他們決定將 Herko 從 Stichting XOOPS 除名。理事會也同時聲名他不再能夠代表 XOOPS 進行任何財務決策，當時所有人仍然希望能夠和平解決來讓社群繼續走下去。
Herko Coomans 拒絕接受並且由他的律師做後續連繫，他的律師提出了下面解決方案：A) Stichting Xoops 將會無償將下面項目轉移給 Xoops Foundation 基金會：
- http://www.xoops.com 這個網域名稱
- 所有跟這個網域名稱以及 XOOPS 相關的品牌智慧財產權
- 現有財務餘額，估計為 10,000 歐元
B) 在這些權力移轉後， Stichting Xoops 必須要解散
違反了上述任何一項協議， Herko 同意為個別協議的違反支付 5,000 歐元(摘譯)
9) 根據 Herko 在討論[14]以及當時的財務資料[15]，基金會在 August 2007 應該還有大約 16,000 歐元，因此在 Stichting XOOPS 帳戶應該還有超過 15,000 歐元。
只有交出 10,000 很明顯是有問題的，因此理事會僱用了律師進行協調，進一步取得了銀行帳戶餘額資訊，截至 Nov. 11,2008 的餘額是 13,485.25 歐元以及 $3,758 美金，美金帳戶接著被移轉到歐元帳戶中。理事會也在這之中得知，Herko 不想要讓人知道他運用了基金會的款項，以 4,000 歐元向他自己購買了 http://www.xoops.com 這個網域，所以基本上 Herko 決定了 Stichting XOOPS 將會支付這筆金額到他的口袋。這當然也是很清楚的利益衝突，理事會也清楚表示這是非法挪用，在 Stichting XOOPS 章程[16]第 6 項清楚提到：
e. 管理團隊同意任何活動都不要求報酬，不過他們被賦與權力，在執行任務所衍生的費用可以獲得補償。
Herko 在 September 2003 以 $18.95 採購了這個網域名稱，當時他是專案負責人，而當時 Mithrandir 在 June 23, 2005 的文章[17]可以看出他是代表 XOOPS 專案進行這項採購。David Ledbury 在同一天的文章也可以證實[18]。
Herko 在 Nov. 22, 2008 以 4,000 歐元將網域名稱賣給 Stichting XOOPS ，這是在理事會通知他被從 Stichting XOOPS 除名之後，當時也告知他不再被允許代表 Stichting XOOPS 進行任何財務決策。因為它是當時唯一能夠存取 Stichting XOOPS 帳戶的人，他提取了 4,000 歐元給他自己，這被視為是非法挪用，因為他應該只能夠獲得 $18.95 。
10) 理事會仍然希望和平解決，也已經提議只要他歸還這些款項，這些款項可以用來支付理事會的律師費用，以及他律師費用的一半，然後專案可以繼續前進。
11) 很不幸的， Herko Coomans 拒絕了這個方案，因此唯一的方法就是進入法律程序
[1] http://www.herkocoomans.net/
[3] http://www.xoops.org/modules/news/article.php?storyid=5170
[4] http://www.xoops.org/modules/newbb/viewtopic.php?post_id=215096#forumpost215096
[5] http://www.xoops.org/uploads/foundation/2005YearReportXOOPSFoundation.pdf
[6] http://www.xoops.org/uploads/foundation/2006YearReportXOOPSFoundation.pdf
[7] http://www.xoops.org/modules/newbb/viewtopic.php?post_id=271279#forumpost271279
[8] http://tinyurl.com/ycxlahd
[9] http://www.xoops.org/modules/news/article.php?storyid=3982
[10] http://www.xoops.org/modules/newbb/viewtopic.php?post_id=279397#forumpost279397
[11] http://www.xoops.org/modules/newbb/viewtopic.php?post_id=279433#forumpost279433
[12] http://www.xoops.org/modules/wfchannel/index.php?cid=17
[13] http://www.xoops.org/uploads/foundation/letterXoopsHerko2.pdf
[14] http://www.xoops.org/modules/newbb/viewtopic.php?post_id=284098#forumpost284098
[15] http://www.xoops.org/modules/newbb/viewtopic.php?post_id=284105#forumpost284105
[16] http://www.xoops.org/uploads/foundation/XOOPS_FoundationStatutes.pdf
[17] http://www.xoops.org/modules/newbb/viewtopic.php?post_id=165567#forumpost165567
[18] http://www.xoops.org/modules/newbb/viewtopic.php?post_id=165544#forumpost165544
-
kiang
老大，我要參選中和市長啦！
前兩天突發其想，以前立法委員選舉黃牛了，最近三合一選舉靠近了，換個比較容易的中和市長試試，跟女友聊到的時候，她還是百般的不相信我可以做這件事情，所以我今天開始填申請表單，也很認真的打了下面政見(規定是 600 字以內，加標點符號我打了接近 550 字，夠認真吧)：
每天會經過華中橋頭，總覺得塞車的問題一直是個困擾，打開窗戶也直接可以面對華中橋上各種車輛的噪音，也許可以藉這個機會積極參與改善的過程。我的專業是資訊技術，俗稱宅男，每天就是面對著電腦過生活，10/7晚上跟女友提到這件事情，她說我不可能，所以我10/8開始打申請表單，某些方面看來這次的參選是基於維護男性的尊嚴，所以男性朋友們一定要支持啊！女性朋友呢？因為一個願意為證明自己而做這件事的男人實在不多，給點同情票也是不為過吧？特別是原本不想投票的朋友，這次有這麼清新的參選人，怎麼可以錯過！‧‧講正經的，台北市有南港軟體園區，也許中和可以在台北縣境內扮演同樣的角色，不確定以這個身份能夠推動到什麼程度，但畢竟自己就具有這樣的專業，相信可以對中和發展軟體產業有些幫助。其次，我所擅長的是將繁雜的行政程序轉換為軟體操作，也許藉著這次實際參與中和市行政運作，可以協助將許多倚賴人工處理的行政程序轉換為電腦軟體來輔助，甚至進一步透過開放原始碼授權免費將程式提供給所有人使用、研究，相信這會是自己身為資訊技術從業人員對社會的最大貢獻之ㄧ。最後，這次的參選並沒有事先安排任何競選的活動，真的有機會當選會努力讓中和市民感覺到有在做事。
—
就在準備相關申請文件的時候發現，那些證明文件要準備幾份怎麼都沒有寫，所以就打電話去中央選舉委員會問，接電話的人感覺非常有經驗，在得知我有意願參選鄉鎮市長同時，很睿智的問了我是哪個縣市，我說台北縣啊，他立刻回應，台北縣這次沒有選舉啊，以後都是官派的！……我女朋友說對了，我的確不可能參加這個選舉……
-
kiang
聊聊平行處理
雲端運算這個新名詞掀起了不少熱潮，但是平行處理的概念很早就存在了，只是很少被廣為討論。
目前比較開放、熱門的就屬 Erlang 與 Hadoop 兩個專案，而許多廠商相繼推出的解決方案雖然使用了相對熟悉的程式語言(GAE 支援 Python 與 Java 、Aptana 支援 PHP )，但是因為各家廠商之間缺乏互通性，轉移不易，急著卡位不知道會不會反而哪天變成被掐著喉嚨 ^^||
平行處理所帶來的好處對程式設計師而言是非常具有吸引力的，因為執行效能會隨著節點的增加而線性成長，而且基本上不需要改寫程式；目前一般的程式開發都會遇到類似問題，剛開始為了方便而將大部分的服務放在同一台主機，在效能遇到瓶頸時就開始把各種服務分離來提升執行效能，接著就是各種形式的快取，或是各種複雜、交錯的解決方案，令人感到沮喪的是每個轉換過程都意謂著大量的程式改寫，對程式開發單位而言可以算是個夢靨。
平行處理是否是萬靈丹？好像也沒這麼神奇，畢竟平行處理領域像是個蠻荒地帶，一些在傳統程式語言唾手可得的資源，在平行處理的世界中好像都得自己來，所以很難去比較說到底是一直重構傳統程式快還是直接以平行處理的環境進行開發快。
平行處理的需求也讓硬體的發展出現變化，以知名的超級電腦為例，台科大靠152 台DL 145 G5 Server 才做出 0.92 teraFLOPS 運算速度 ( http://www.cc.ntust.edu.tw/front/bin/cglist.phtml?Category=88 )，而昇陽 Sun Blade X6275 可以在42U機架上透過 48 台伺服器主體支援總計768個處理器核心，最高效能可達9 teraFLOPS。NVIDIA Tesla S1070 更是基於 GPU 技術的突破，在 1U 主機上就可以提供 4 teraFLOPS ，具有 960 個運算核心，同樣的機架可以提供超過 168 teraFLOPS 運算能力。
從硬體的發展看來，軟體開發走向平行處理是必然的趨勢，就看自己什麼時候覺醒了
-
kiang
AGPLv3 相容於 GPLv3 ？
最近參與了 FrontAccounting 社群關於授權方式的討論：
http://frontaccounting.net/punbb/viewtopic.php?id=398FrontAccounting(FA) 的前身是 OpenAccounting(OA) 與 webERP ，其中 OA 已經很久沒有更新了，而 OA 與 webERP 都是使用 GPLv2 授權，因此 FA 在 2.0 與早期版本都是使用 GPLv2，只是在上面討論發起後，開發者似乎有意將授權轉換為 AGPLv3 。
雖然 OA 是改寫自 webERP ，據說已經完全沒有使用到 webERP 的程式碼，而 FA 的開發者取得 OA 作者的同意，將程式的授權更新到 GPLv3 。接著， FA 的開發者發現 GPL 授權內容有提到， AGPLv3 相容於 GPLv3 ，因此認為可以直接將 GPLv3 授權轉換為 AGPLv3 ，所以就決定在 FA 2.1 版開始使用 AGPLv3 授權。
我在 gnu 網站找到了一則關於相容的說明：
http://www.gnu.org/licenses/gpl-faq.html#WhatIsCompatible這才了解到，GPL 所謂的相容是指兩個不同授權的程式可以放在一起，像是核心程式使用 AGPLv3 時，模組可以選擇使用 AGPLv3 或 GPLv3 任一授權方式，並非如同 FA 開發者所指能夠直接轉換。接著針對這點發現提出回應，也將內容發到 gpl-violations 的通訊論壇確認。
接著 FA 開發者暫時將以 AGPLv3 授權的程式撤下，透過各種方式進行意見的交流，不過他們提到已經取得 OA 作者的完整授權，選擇 GPLv3 或是 AGPLv3 都可以，只是希望聽聽大家的意見。
我提到，對網頁介面為基礎的程式來說，AGPLv3 就好像是共產主義一樣，任何人只要能夠存取程式就可以要求完整的原始碼，而 GPLv3 就好像是資本主義下的稅負一般，即使總是有人抱怨其他人的逃漏稅，但這不應該是改選擇共產主義的理由。
我並不喜歡那種抱著投機心態使用 ASP/SAAS 授權模式的商業模式，但是我更不喜歡一堆不相干的人無時無刻吵著要程式碼的態度，這是我排斥使用 AGPL 授權的原因。在討論中還有提到，那些使用 ASP/SAAS 方式迴避 GPL 授權的供應商，他們所修改的程式碼還是有回到社群的機會，因為工作中接觸到那些程式碼的工程師或是合作廠商，只要他們在放棄合作與工作前提出要求，GPL 有著不得加諸限制的條款，他們原則上可以合法取得完整的程式碼以及散佈那些程式碼的權力。如果社群中真需要那樣的功能，而那些公司也沒能夠妥善照顧所有可接觸程式碼的工程師，相信這些程式碼還是有機會回到社群。
最後， FA 選擇了 GPLv3 ，不過也語帶保留的提到或許未來還是有可能改採 AGPLv3：
http://frontaccounting.net/punbb/viewtopic.php?id=480簡單的說， GPLv3 跟 AGPLv3 兩個授權可以放在一起，但是不能換來換去。
-
micmic
太多 lincense 了,GPL ,LGPL ,MPL ,MIT ,BSD ,APACHE 的叫什麼我忘了….
,其實我認為 opensource 的 erp 應該有機會做的起來. -
kiang
APACHE 的就叫 APACHE 啦
ERP 不是件簡單的事情，能夠凝聚眾人的智慧是最好不過了。
-
-
kiang
雜記 – 09120013
在結束了一天消耗腦力的工作後，關上辦公室的燈、把門鎖上，走下樓梯，眼前兩隻野狗帶有猜疑意味的望著我，當我朝他們走去，他們就害怕的鑽進草叢中；我的機車就停在草叢旁，從機車拿出雨衣在穿的時候，我腦子裡在想，如果那兩隻野狗突然撲上來會怎麼樣？只是機率很低，因為牠們在害怕。
早上到了公司，拿了泳具就往游泳池過去，今天有蓮蓬頭的更衣室全部上鎖了，只能使用游泳池旁那個沒有水的更衣室，然後透過露天的蓮蓬頭把身體沖涼。今天還是只有我一個人使用游泳池，一個人來回游著時腦子裡在想，如果哪天遇到飛機失事迫降海中央，我有沒有能力帶著女友脫離險境？邊游邊想，不知道自己現在有沒有能力橫渡日月潭，不過如果真的發生那種災難，可能想辦法延長自己在海上漂流的時間比較要緊，因為通常海中央是很難游到陸地上的。想著想著，耶，今天有另外一個人來游耶，而且好像是女的；不過今天差不多了，晚點還要上班，游太累會打瞌睡。
中午吃飯的時候，學校社團利用開學期間招募新血，加上暑假剛過，感覺人多到有點讓人不適應，而且還會被誤認為學生要塞社團文宣。門口轉角那個閒置已久的吧台，這個學期開始有飲料店進駐，還有賣水果，$25 元一盒，比一般外面 $35 便宜些；還有廠商派駐的電腦販售點，有賣之前想買的小筆電，不過已經答應一個朋友接手他的 EEEPC ，加上女友應該不可能答應這種預算，看看就好。
晚上，…
其實我不太懂自己想寫些什麼，只是總有些片斷的想法在腦中閃過，偶爾回想時卻又沒有當下那麼完整，也許是我缺乏用文字記錄的習慣，或是每天盯著電腦打字已經讓自己的腦袋變得渾鈍了。這樣子一天過一天，也許有蠻多新鮮的東西發生，卻因為工作中的程式邏輯塞滿腦袋，感覺這退伍快一年的記憶有些空白。
缺乏安排？星期二晚上有朋友的小聚會、星期三晚上讀書會、星期四晚上接著可能要去學校跟學弟妹做技術交流；早上除非游泳池不對外開放，否則都會讓自己游個 20 ~ 30 分鐘，有時不想游泳會去拉拉單槓，假日也都是往外面跑，上個週末才剛騎機車來回宜蘭一趟。
心情不好？沒特別的感覺耶，身邊的人是哭、是笑、是生氣、是緊張，我好像都那副樣子。
從某個角度看，也許這算是杞人憂天吧，人在福中不知福；換個角度，這個過程好像少了那麼些感動，那種讓人覺得自己活著的過程；換個角度，這是基於本能上危機意識的反應，因為快 30 了；換個角度，應該是過去的生命起伏比較大，現在相對顯得平淡；換個角度，晚餐吃完牛肉麵不應該再塞兩顆月餅跟一大杯豆漿，這樣好像會讓人有點睡不著…
-
kiang
分享快樂blog存摺
商周的活動：
http://www.businessweekly.com.tw/event/1000/passbook.php
快樂1
老大－放假的時候想好行程去找妳相信會快樂些
快樂2
鏡子裡的小平頭－廢話，四肢健全而且提早退伍（扁哥，多關心有為青年在營中浪費的生命吧～！）快樂3
旅館櫃台小姐－看就知道在期待小費這檔子事情
快樂4
機車拋錨的熟女－我真的很想停下來幫忙推車，真的
快樂5
學長－我知道你希望很多東西教沒兩次我就全都會，這樣子你就可以摸魚摸到爽
快樂6
輔導長－我知道你想要我連美工繪圖都一級棒，雖然我好像是個程式設計師
快樂7
明天退伍的組長－會啦，我會幫你問xx不動產的工作環境，如果我沒忘記…
快樂8
留守的同梯－我會帶好料的回去啦，滷肉飯還是茶葉蛋？
快樂9
書的編輯－會啦，新書會交稿啦，不過就拖了快一年嘛…
快樂10
雜誌編輯－感謝你每個月快截稿時都會想起我，我也會好好想想要給什麼稿
快樂11
TWPUG網友－我有空就會幫你試試那個問題啦～
快樂12
路人女甲－我會用雙眼盯著妳短到不行的裙子來增加妳的自信指數
快樂13
前面那個騎士－機車犁田是我自己手賤，放一百二十個心
快樂14
想要跟我尬車的陌生騎士－你那五百CC的重車真的比我125CC的快，我認輸
快樂15
堅持要卡在路中央的汽車－我確實過不去，你贏了
快樂16
街頭素描的畫家－我們其實很想要坐下來給你畫一張
快樂17
給我活動連結的大姐－我快寫完了，真的
快樂18
智財權的前輩－我接受潛在價值換取技術支援，多給我些暗示吧
快樂19
覺得我只會鬧場的活動主辦人－在台下我收斂很多了，真的，下次讓我在台上鬧吧！
快樂20
瑄瑄與水電工電影的導演－我支持國片，你有缺演員嗎？（有沒有比瑄瑄年輕的、漂亮的、…）-
tokimeki
我其實已經不太在乎自己是否快樂了，因為有更重要的事情等著我去作。
-
kiang
別用太多理由去搪塞自己真實的想法，許多時候，你所表達的只是你認為符合周遭人們期待的意見；而也很多時候，那些人根本沒這麼想，你不過是用了先入為主的想法取代了他們想法的其他可能。
多試著靠近人群吧，看看自己平常不看的、認為庸俗的文字，別活在自己的世界中
-
-
kiang
第一個下標者結案了
前不久開標的案件（ http://blog.twpug.org/post/1/276 ）在今天結案了，客戶主要是針對已經導入使用的 VtigerCRM 系統提出疑問，雖然有些狀況無法現場立即解決，過程還算順利。
他們是因為看到我在書中的介紹，所以就開始導入使用，只是他們並沒有使用到大部分的功能，只是利用 VtigerCRM 記錄與客戶之間的互動過程，也用它的統計圖表功能作為發展的參考；因為主事者確實要求客服人員進行記錄，累積了相當多的資料，算是目前看到最具規模的導入狀況。
在現場也另外安裝了 SugarCRM 的最新版本讓他們測試，他們表示 SugarCRM 好像比較適合他們，只是現有系統已經累積了不少資料，移轉工作又沒辦法輕易完成，因此選擇期待 VtigerCRM 的新版本能夠解決他們遇到的狀況。對於一個使用者而言， SugarCRM 確實在程式的功能或穩定度上都要強過 VtigerCRM ，只是 SugarCRM 的授權中要求得在網站下方放上他們的圖示與連結，讓許多朋友不願意使用。他們今天也有一場對客戶的活動，請我幫忙看看進行過程問題；我並沒有在活動現場待很久，因為活動所介紹的東西我已經有一定的熟悉度。接著跟接洽的人討論，活動的主講人感覺比較緊張些，介紹產品時採用平鋪直敘的方式將畫面上的所有細節交代清楚，但是參與的朋友應該會比較需要情境模擬的形式來確實知道產品如何應用，細節的部份也許能夠以書面的形式提供給與會人員。另外一個問題是，主講人提到了許多技術方面的名詞，可能會因為產生疑問而模糊了活動的焦點。
最後還聊到了他們希望拓展的新業務，只是人力有些吃緊，而且台灣地區的市場也沒有大到值得砸下重金投資，部份業務也還需要一點時間來讓發展進入成熟階段，貿然加入新業務可能風險不小。公司因為主事者積極的態度而成功切入了目前業務範圍，相信在這樣的企業文化中公司會持續進步；另外，他們給了比得標金額還多的車馬費，感覺有些不好意思
mOrris are discussing. 
中和人, 
micmic are discussing. 
kiang, and 
mOrris 18:02:35 on 2010 年 02 月 25 日 Permalink
?!?!?! 有機會瞭解一下
kiang 18:11:05 on 2010 年 02 月 25 日 Permalink
今晚碰面聊嚕，看樣子我得坐公車了 …