Source favicon15:45 1935年:台灣博覽會 » ilyagram
西元1935年適逢日本統治台灣40週年,殖民政府特於該年10月10日至11月28日期間,舉辦始政40週年紀念博覽會。該會的目的在於展示日本統治台灣40年來的政績。 該會由當時總督中川健藏擔任總裁,總務長官平塚廣義擔任會長,協辦單位為台灣電力會社。 三大展覽會場:博覽會第一會場設於台北市公會堂(今中山堂)及公會堂以南的三線路(今中華路),產出品為農(糖業為主)、林、礦等原料產業及交通土木;第二會場設於台北市新公園,展出品為日本各州縣的特產及文化演藝事業;分館設於草山(今陽明山),展出品為南洋各國的風光。 每項參展品皆經過評審:各項參展品,依其出品的種類及性質分為原料產業、工商業、交通、建築和教學及其他社會設施三大類;各類均委託具有專門技術者為監查員,以公正嚴格之態度分析試驗、分解檢查及實地演練,評定優良者予以表揚。 台灣傳承文化事業 Taiwanheritage.com:1895-1945:見證台灣總督府。台灣博覽會 - 藉以傳播統治政績及日本文化。
Source favicon15:05 統治的腳:專賣 » ilyagram
...從日俄戰爭間的1905年開始,台灣全然以島內的收益來供給。專賣制度是台灣總督府所經營之國家事業。從原料到販賣一手總攬管理的國營事業,不僅是可靠的財源,特別許可的手續過程也可以利用於人心的操弄。台灣島民之生活與經濟也從舊清朝型態大幅轉換為依存日本型態。被賦予專賣特權的漢民族地主階層被視為地方上的穩固勢力,被編入親日御用紳士,在日俄戰爭期間動員於軍資獻金或軍事公債〈4〉,在日本統治的初期十年形成明確的維持體制派。 成為重要財源的專賣是在1897年將鴉片、1899年將食鹽、1901年將樟腦統一為台灣總督府專賣局,為將樟腦與日本國內生產做調整,於1903年設立日台統一的專賣制度。專賣總收益中樟腦的利益成穩定成長,但1900年產量驟減是由於北部泰雅族中大嵙崁族的反抗,1,000餘人的事業負責人、雇員等被迫下山。為了鎮壓,出動的守備軍裡也有中隊長以下多數死傷,當局不得不採取封鎖政策。1902年7月發生賽夏族的南庄抗日事件,轉變了「理蕃」政策,但未影響樟腦產業。1905、6、7年樟腦收益超越鴉片收益〈5〉。1900年鴉片吸食者為16萬9064人〈6〉。1905年台灣原住民族的「蕃社」有705社、「蕃人」有22,002戶、133,195人〈7〉。其中居住於樟木原生林的泰雅族及少數的賽夏族合計有262社、7,262戶、共計24,021人,成為居住於樟腦產地的累贅。後藤新平稱為樟腦專賣,在「成功發揮新型統制經濟的妙處」這一點獲得高度評價〈8〉。 台灣日本綜合研究所,日俄戰爭與台灣總督府之原住民政策,政治大學日本語文學系教授傅琪貽。
Source favicon14:32 MSN Messenger X Virtual Earth » Jan's Tech Blog
原來MSN已經將Messenger與Virtual Earth整合,一起可以Share同一張地圖。這個也是Jan這兩天閱讀Dare Obasanjo aka Carnage4Life才知。 這App十分有用。因為當大家透過IM約會要找地方見面時,這個App就發揮很大作用。當然一方面,你要瞞騙MSN說你是美國人,另一方面你要用美國地圖才可以吧。只要你符合這兩個條件,那麼打開MSN Messenger,在Activities之下就會見到Virtual Earth Shared Map這App。 當然,如果GTalk有這樣的Integration會比較理想,因為Google Maps比MSN Virtual Earth看得更多,至少中、港、台也有覆蓋吧。...
Source favicon14:03 Upcoming.org Team Joins Yahoo! » Jeremy Zawodny's blog
Over on the Yahoo! Search blog, Paul says: In just a few years, most of it spent on nights and weekends, the Upcoming team has built an excellent site with a loyal and growing following. Now that they’ve joined Yahoo!, together we’ll build a social events platform that will integrate with our existing events offering and other areas of Y!, and will continue to support all web users in an open, participatory way. Andy says: I've always had a warm...
Source favicon12:33 What's Upcoming at Yahoo! Local » Yahoo! Search blog
As readers of the Yahoo! Search blog know, our vision is a far-reaching one -- to enable people to find, use, share, and expand all human knowledge. Events are a particularly exciting area of human knowledge -- chock full of...
Source favicon11:28 RSS consultant needed » Tim Yang's Geek Blog

A friend and IM-collaborator, Eric Thom of RSSapplied.com, needs an RSS consultant and blogger immediately.

RSS Applied has been focused on the business opportunities presented by RSS and Weblogs for years, and we’re ready to bring another person onboard.

Source favicon11:28 Template Creation Wizard for PowerPoint » Jan's Tech Blog
顧名思義,這Add-in就是幫助你建立PowerPoint 2003的Template。要做很多Presentation,又想要自製Template的話,按此下載。...
Source favicon07:49 How I got to Google, ch. 1 » Official Google Blog




-- via craigslist, and thanks for asking. Our engineers, though, tend to come by more varied, and occasionally odder, routes. Some get recruited out of grad school, or by friends or former colleagues. Others just send their resumes to jobs@google.com. For a few engineers, though, the path has been more interesting. Peter Bradshaw, for instance, built “a music playing system based on printed cards with barcodes and webcams. Includes lego!” (No, I don’t know what that means, either.) Over the next few weeks, we’re going to post some of their stories.



Like this one, from Systems Administrator Aaron Joyner:





My story started when I came into work one morning and was unable to look up something on Google. Being the sysadmin for my company at the time, it was my responsibility to resolve the problem, so I started poking around. It turned out that our DNS server [ed: all the jargony stuff you'll hear in this anecdote refers to the software that websites use to connect and talk to each other] was returning an error when trying to look up google.com, specifically a server failure error. Just as I’d convinced myself that it wasn't our problem but Google’s, the problem suddenly resolved itself. I promptly forgot about it and went back to my regular work.



But then I came in the next morning and had exactly the same problem, so I started looking at Google's DNS responses very closely. It became clear that the specific combination of delegations and glue records they were returning [ed: see note above] would result in an eventual error approximately once per day, and this would then take it about five minutes to give up and try again. Not entirely convinced that I should point the finger at Google yet, I posted a message to my local Linux Users Group asking if anyone had had problems with resolving google.com addresses and got a couple "Yeah, I did have a problem like that once recently" responses.



Thus reinforced, I headed over to Google.com, found the "Contact Us" page and the "Report a problem" link, chunked in a brief problem description and a link to the archived copy of the long technical description from that same mailing list thread, and thought to myself, "Gee, I'll never hear about that again." But then one afternoon a week later I get an email that said, basically, "We've received your problem report, and forwarded it on to the appropriate department, if they need any further information they’ll contact you. Thanks." Again, I thought, "Gee, how nice. I'll never hear about that again."



But that evening I got an email from Dave Presotto (the guy who wrote the DNS server for Plan9) saying that he was looking into it and would get back to me. Forty-five minutes later I got another email, this one describing how he believed they had accidentally fixed the problem earlier in the week due to general code cleanup, and asking what I thought of the solution. After I recovered my senses and stopped bouncing around the room, I had a few email exchanges with Dave, in the course of which I asked casually if they needed any good sysadmins out in Mountain View. He referred me, and the rest is history.
Source favicon01:41 » Jedi's BLOG | Jedi.org

Lawrence Lessig 認為,程式碼就是虛擬世界中的法律:程式規範著虛擬世界,一如法律規範著現實世界。基本上我相信且贊同這樣的看法。不過,在虛擬世界之外,在這個血淋淋的現實之中,我對於法律也有著一些小小的想法。

我相信,法律乃奠基於絕對的不信任。因為人跟人之間失去了信任,不再相信對方是否還有善意,所以纔用白紙黑字寫明了最終的底線──在一切信任及善意都瓦解之後,人跟人之間所必須要維持的最後一吋疆界。

日前有新聞報導,「台北市中心診所助理研究員姚素珍,九十一年間在醫院內替一名休克已無心跳的病患實施急救,卻因未具醫師資格而觸犯醫師法」。以前人說,「救人一命勝造七級佛屠」,現在救了人卻要被處罰,這到底是為什麼呢?因為人們不再相信對方的動機,不再相信對方的技術與能力,不再相信對方所發出的善意。當「自己」變成唯一重要的事、當「別人」變成完全不重要的事時,人的恐懼將無止盡地膨脹──這可不是對別人的恐懼,而是對自己的恐懼,因為失去了信任的能力而湧現的恐懼。當創立法律的人訂出了這樣的條文,當執行法律的人依此做出了審判,就意味著民主政治下過半數的人早就同意了這種摒除一切信任而採行的手段。

所以,對於這類事件的發生,驚惶已嫌太遲。接受,或改變。這就是現實。

記得當我年幼的時候,家母跟我說過一個故事:

有一家人帶著小孩跟父母移民美國,平常夫妻上班時,小孩就交給(小孩的)祖母照顧;有一天,小孩咳嗽了,祖母就在家附近採了藥草,煎了中藥要給小孩喝。這件事碰巧被鄰居發現了,於是鄰居就向政府通報,接下來警察就逮捕了那位祖母。她的罪名是,行使密醫行為並危害未成年兒童安全。

在那樣一個種族歧視、族群對立、歷經殖民戰爭與南北內戰的國家,「人權」建立在極端的不信任上,「人權草案」發生於全然沒有人權的時空,這纔造就了今日這樣的社會。人民早就學會了不信任,人民早就接受了不信任的態度,上述的故事也就沒甚麼好大驚小怪的了。

罔顧這種國情與人民成長背景的不同,執意把法律條文的內容修改成與他國相仿,身負立法修法大任卻「法他人之法,未法他人之所以為法」,這叫混蛋。至於放任混蛋的則是蠢蛋。我們的國家丟不開人情世故,卻要走極端不信任的路,這讓白紙黑字成了笑裡藏刀;而在這場混亂中,律師扮演著攻擊用的武器,絲毫不憐憫地瓦解著眼前的障礙。

我這個人從來沒有喜歡過律師這種職業。這大概跟我不喜歡吵架有關。我當然很喜歡探求事物的道理,推演萬物的邏輯,與人激烈地答辯,沈思或冥想;但這一切都是希望取得共識,希望讓彼此成長,希望修正自己的曲解,希望互相體諒,希望世界更美好。而我所體認到的律師這份工作,似乎執著於一場又一場的戰役,致力於一次又一次的勝利,巴不得將對手打得一敗塗地;他們能從對手身上習得各種刁鑽的戰術而非一個人的思想意志,他們能用各種艱澀的術語和條文混淆妳我的心智,而我卻很難看穿,他們心中的理想世界又是如何。

我不得不承認,我對律師的不喜歡,已經到了畏懼的地步。因為失去了信任而產生的畏懼。律師是凶猛的武器,因此我害怕若得罪了他們,有一天他們就會趁機對我做些甚麼。我如此懦弱,想一想實在是很可笑。

我猜想這也是為什麼我喜歡電腦的世界略多於現實世界的原因之一:妳永遠可以摒棄某一種程式語言而創出自己的程式語言,徜徉在自己的世界裏,實驗並驗證自己的夢想;然而,妳卻沒辦法輕易地說某套法律不算數而自創一套。

我不喜歡沒有信任、缺乏善意的環境,而唯一反擊的機會卻是保留遭到被判、受到惡意的可能,用純真的心去信任、去發出善意。這種付出是注定犧牲的,這條路是注定冷清的,然而也祇得知其不可而為之;不能用強加的力量迫使其他人也這樣,也不能用不信任的力量來對付不信任;若能有朝向相同目標的旅伴固然可喜,落得隻身一人也無可怨嘆。就祇是相信,就祇是抱著善意,這種純真的力量或許微薄,卻很強韌;祇要相信,就有希望,就有未來。

或許 J.R.R. Tolkien 的 《 The Lord of the Rings 》所訴說的也是相似的想法吧。

至少,我如此篤信著。


^==Back Home: www.chedong.com

<== 2005-10-04

==> 2005-10-06