========================================
剛剛打了很長一篇不小心按到，全部被洗掉了...orz
簡單講，Picasa 模式不可行，你難道要每個程式都自己帶一份 wine
針對自己的程式去修改過讓他能夠支援？這件事情的難度沒有像你
想像的那麼低，要有能力修改 wine，開發人員得同時「精通」
Windows 和 Linux 平台上的程式設計，才做得到這件事情
也只有像 Google 這樣的公司，有本錢玩得起這種遊戲
何況，他的 Picasa 也不是直接用 wine，而是一定得用自帶修改版
即使是這樣，中文輸入法或中文顯示仍然不是在每個 distro 都正常
wine 的支援度和穩定性，距離真正的 Windows 事實上還是差很遠的
而當 wine 好不容易提昇支援度的同時，Windows 上的新功能以
成倍數的速度在持續成長，加上 .net，可以遇見，wine 的相容性，
在微軟強勢高速發展大量新技術的狀況下，將會越來越差。
Mono 面臨的情況也完全一樣，當他做到跟現有的 .net 完全相容時
微軟又會推出大量嶄新的規格，這時候 Mono 會再次陷入挨打的情況
不管怎麼做，就只能在後面苦苦追趕，始終不可能有完全相容的情況
微軟髮展新規格和新技術的速度，在雄厚資本挹注下，是無與倫比的
而且這些新技術大部分都有非常完整的文件和範例，可免費使用。
其中甚至已經有越來越多被翻譯成多國語言，開發環境非常的友善。
Windows 上的開發工具也是多樣且成熟，而且大部分都非常的好用。
即使是十幾年前的老舊開發工具，仍然比 Linux 上最新的開發工具
要好用上很多倍，先進上很多年，這是 Linux 開發人員的痛。
你在 Windows 上要知道系統上有幾個磁碟機，只要寫「一行」。
而且這一行保證搬到任何的 Windows 系統都可以如預期的運作。
在 Linux 上要做到同樣的事情，你得使用 HAL、DBus，呼叫數十個
複雜且「幾乎找不到文件」的函數，而且不同 HAL 和 DBus 版本下
作法和支援度都各自不同。到了 FreeBSD，作法又完全的不一樣了。
而即便你爬各種程式碼，好不容易搞出會動的版本，
拿到不同的 distro 下可能又不會動了，不同的桌面環境下
可能又不能用了，而且你找不到錯在哪裡，也沒有任何參考文件。
你只能拿一堆看不懂的原始碼過來，自己慢慢爬，運氣好找得到解法
費盡心力做出來的東西，往往卻有很高的機率不會正常運作。
這樣的程式除非是真的很熱血，沒人會想要寫。
在 Windows 下插入一片光碟即可使用，在 Linux 下，要用程式
去 mount/umount 一片光碟，有七八種方式，在不同的 distro，
不同的桌面環境，不同版本的 HAL 下，建議使用的方式都不同，
而且每種都不保證有辦法正確運作，很悲哀不是嗎？
自由開放的代價，就是亂七八糟的相容性，百家爭鳴的規格混亂
帶來的就是程式設計師要花大量時間，去處理這些和程式本身
的功能完全不相幹的事，而即便是努力處理了，還不一定能夠克服
更糟的是你處理好之後，可能隨時會在下個版本的 Linux 又壞掉。
這樣的開發環境，除非 Adobe 一類資本雄厚的公司，誰會有興趣？
你可以說使用 Java、使用 Mono、使用 Qt 不是就跨平台了嗎？
實際上卻不是這麼回事，要處理的事情仍然是很多，而且這些平台
和函式庫之間，也存在著許多自己的相容性問題，永遠處理不完。
很多各平台上特殊的功能，仍然必須使用低階的方式來做，
而這些方式，往往都是複雜且相容性混亂的。
要在程式裡面啟動瀏覽器，在 Windows 只要寫一行，且保證能用。
在 Linux 桌面下，至今沒有任何一個可以保證正常運作的方式。
Gnome，XFCE，KDE 都各自使用自己的解決方案，各家都不同
為了偵測系統上有什麼瀏覽器可以用，需要的又是大量
撰寫困難，且不保證可以正常運作的程式碼。
這樣惡劣的開發環境，除非真的是很熱血的人，誰吃飽太閒？
要呼叫預設程式開啟某個檔案，在 Windows 上只要一行，保證可用
在 Linux 上你要讀完七八份非常長的英文文件，然後寫上
上千行的程式來處理複雜的 mime type 和各種複雜的 xml 檔案
重點是，即便你寫完了，還是不一定可以正常運作。
所以 gnome 提供了 gnome-open，XFCE 提供 exo-open，KDE
則是用和大家都不相容的自家解決方案，你說，開發者要選哪邊站？
xdg-open 是最近在推的統一解決方案，不過顯然尚未成氣候。
在 Windows 上只要寫一行，在 Linux 下卻是搞不完，
這樣的例子不勝枚舉，我實在不忍心繼續寫下去了...
不想一直打擊各位對 Linux 的信心，只是有些殘酷的事實要認清。
簡單講，Picasa 模式不可行，你難道要每個程式都自己帶一份 wine
針對自己的程式去修改過讓他能夠支援？這件事情的難度沒有像你
想像的那麼低，要有能力修改 wine，開發人員得同時「精通」
Windows 和 Linux 平台上的程式設計，才做得到這件事情
也只有像 Google 這樣的公司，有本錢玩得起這種遊戲
何況，他的 Picasa 也不是直接用 wine，而是一定得用自帶修改版
即使是這樣，中文輸入法或中文顯示仍然不是在每個 distro 都正常
wine 的支援度和穩定性，距離真正的 Windows 事實上還是差很遠的
而當 wine 好不容易提昇支援度的同時，Windows 上的新功能以
成倍數的速度在持續成長，加上 .net，可以遇見，wine 的相容性，
在微軟強勢高速發展大量新技術的狀況下，將會越來越差。
Mono 面臨的情況也完全一樣，當他做到跟現有的 .net 完全相容時
微軟又會推出大量嶄新的規格，這時候 Mono 會再次陷入挨打的情況
不管怎麼做，就只能在後面苦苦追趕，始終不可能有完全相容的情況
微軟髮展新規格和新技術的速度，在雄厚資本挹注下，是無與倫比的
而且這些新技術大部分都有非常完整的文件和範例，可免費使用。
其中甚至已經有越來越多被翻譯成多國語言，開發環境非常的友善。
Windows 上的開發工具也是多樣且成熟，而且大部分都非常的好用。
即使是十幾年前的老舊開發工具，仍然比 Linux 上最新的開發工具
要好用上很多倍，先進上很多年，這是 Linux 開發人員的痛。
你在 Windows 上要知道系統上有幾個磁碟機，只要寫「一行」。
而且這一行保證搬到任何的 Windows 系統都可以如預期的運作。
在 Linux 上要做到同樣的事情，你得使用 HAL、DBus，呼叫數十個
複雜且「幾乎找不到文件」的函數，而且不同 HAL 和 DBus 版本下
作法和支援度都各自不同。到了 FreeBSD，作法又完全的不一樣了。
而即便你爬各種程式碼，好不容易搞出會動的版本，
拿到不同的 distro 下可能又不會動了，不同的桌面環境下
可能又不能用了，而且你找不到錯在哪裡，也沒有任何參考文件。
你只能拿一堆看不懂的原始碼過來，自己慢慢爬，運氣好找得到解法
費盡心力做出來的東西，往往卻有很高的機率不會正常運作。
這樣的程式除非是真的很熱血，沒人會想要寫。
在 Windows 下插入一片光碟即可使用，在 Linux 下，要用程式
去 mount/umount 一片光碟，有七八種方式，在不同的 distro，
不同的桌面環境，不同版本的 HAL 下，建議使用的方式都不同，
而且每種都不保證有辦法正確運作，很悲哀不是嗎？
自由開放的代價，就是亂七八糟的相容性，百家爭鳴的規格混亂
帶來的就是程式設計師要花大量時間，去處理這些和程式本身
的功能完全不相幹的事，而即便是努力處理了，還不一定能夠克服
更糟的是你處理好之後，可能隨時會在下個版本的 Linux 又壞掉。
這樣的開發環境，除非 Adobe 一類資本雄厚的公司，誰會有興趣？
你可以說使用 Java、使用 Mono、使用 Qt 不是就跨平台了嗎？
實際上卻不是這麼回事，要處理的事情仍然是很多，而且這些平台
和函式庫之間，也存在著許多自己的相容性問題，永遠處理不完。
很多各平台上特殊的功能，仍然必須使用低階的方式來做，
而這些方式，往往都是複雜且相容性混亂的。
要在程式裡面啟動瀏覽器，在 Windows 只要寫一行，且保證能用。
在 Linux 桌面下，至今沒有任何一個可以保證正常運作的方式。
Gnome，XFCE，KDE 都各自使用自己的解決方案，各家都不同
為了偵測系統上有什麼瀏覽器可以用，需要的又是大量
撰寫困難，且不保證可以正常運作的程式碼。
這樣惡劣的開發環境，除非真的是很熱血的人，誰吃飽太閒？
要呼叫預設程式開啟某個檔案，在 Windows 上只要一行，保證可用
在 Linux 上你要讀完七八份非常長的英文文件，然後寫上
上千行的程式來處理複雜的 mime type 和各種複雜的 xml 檔案
重點是，即便你寫完了，還是不一定可以正常運作。
所以 gnome 提供了 gnome-open，XFCE 提供 exo-open，KDE
則是用和大家都不相容的自家解決方案，你說，開發者要選哪邊站？
xdg-open 是最近在推的統一解決方案，不過顯然尚未成氣候。
在 Windows 上只要寫一行，在 Linux 下卻是搞不完，
這樣的例子不勝枚舉，我實在不忍心繼續寫下去了...
不想一直打擊各位對 Linux 的信心，只是有些殘酷的事實要認清。
沒有留言:
張貼留言