新專案 LXTerminal 和 LXLauncher2 嘗鮮！

長久以來，總是找不到 Lightweight 的終端機程式，因此在 LXDE 上一直好像缺少了什麼。而 GNOME-Terminal 之肥，實在令人不敢恭維；XFCE4-Terminal 夠輕，但需依賴 XFCE4-Library ，在 LXDE 裡使用就顯得有點愚蠢；而 Roxterm 什麼都好，但效能極差，在我的 EeePC + Compiz 上，回應的速度實在是令人難以接受；至於 Sakura，因缺少 Process Sharing 機制，所以記憶體用量大，完全無法與 XFCE4-Terminal 相比；而 Evilvte 縱使省掉 GUI ，但因為 Based on sakura 所以情況差不了多少，Lilyterm 等其他號稱輕量的 Terminal，則也都幾乎有著相同的缺點。有些 Terminal 還使用了 Dbus ，更是先被我打上大叉叉。

其實這得怪罪於 VTE 本身的癡肥和問題，使 Terminal 的開發者沒有一個不用 dirty hacking 的方式，去解決所有的 Bugs 和減少記憶體用量，研讀各家的 Source Code 就能發現其端昵。在自己實作後，也發現其難度。

但為了使 LXDE 有個良好又輕量的開發環境〔只是為了這單純的目的〕，LXTerminal 還是誕生了，雖然目前功能不多，但可支援 Tab、更改字型、剪貼字串，比較可惜的地方是尚未支援 Process Sharing，所以記憶體用量上稍微大了些。不過此功能已著手開發，在正式 Release 時就會支援。

EeePC 上的 LXDE

另外從 Screenshot 裡可以看到，LXLauncher2 緒勢待發，架構其實已經完全改變，現在可支援多層目錄，背景也改用 Cairo 畫。其中有趣的是，改用了 gnome-menu 來處裡 .desktop 等分類的問題，不過別擔心， gnome-menu 並不需要依賴其他 GNOME 的東西，總體上也還算輕盈。

據 PCMAN 所說，在 svn head 的 gnome-menu 改用痴肥的效能殺手 gio，而現在版本只有使用 GLib，所以未來將考慮 fork 目前的版本，或許將會叫做 lx-menu 也說不定。

或許有人會好奇，LXLauncher 連 1.0 都還沒出，怎麼就出現了 LXLauncher2 ？因為 LXLauncher 一直只是實驗階段的實作，擁有不少問題，所以將可能如同 lxsession 被放棄。而這新版 Launcher 其實全名叫做 LXLauncher-gmenu，是因為要與之前版本的 Launcher 做區分，所以我們暫且稱做 LXLauncher2，以防混淆罷了。

目前這些新的專案，可從 LXDE SVN 上找到，有興趣的人可以嘗鮮看看。 :-)

留言

  1. Yuren Ju2008年6月16日 上午9:20

    lxlauncher2 跟 gnomefiles 裡面的 lxlauncher-0.2 不一樣嗎？我看 0.2 好像也支援了 libgnome-menu。

    回覆刪除
  2. Fred Chien2008年6月16日 下午1:54

    lxlauncher-gmenu 最後還是被直接當成下一版的 lxlauncher 0.2。

    不過在 Release 之前，我們都把它當做新的 Project 來看，因為它是完全重寫的專案。

    所以以後仍稱為 LXLauncher ，其他只是過渡期的名稱。

    回覆刪除
  3. 匿名2008年6月16日 下午2:25

    hi Fred, 您寫 code 我很尊重您的專業，也很高興這個社會有您這樣的善心人願意投身自由軟體。我只是個無恥無貢獻自由軟體消費者。但您指名道姓列舉這麼多的 Terminal 貶損他人成就，來凸顯自己 code 的偉大，這樣做未免太不道德了。

    我知道自己生的小孩最好，您的 code 如果不好也不會願意發表，但別人的 code 也相同是他人心血。正面評論，缺失報告，這很好，任何人都歡迎，但你的表答方式，除了討戰外，我看不出任何建議及價值。

    貶損他人然後強調自己好，這樣的宣傳手法是很不道德的。

    lloyd huang

    回覆刪除
  4. 匿名2008年6月16日 下午2:50

    evilvte 作者對本文的回應：
    http://hyperrate.com/topic-view-thread.php?tid=5284

    回覆刪除
  5. Fred Chien2008年6月16日 下午4:09

    『正面評論，缺失報告』

    首先，我已指出一些解決方法和問題，並非無的放矢。若是 Terminal 的開發者，應該曉得我所指出的問題在哪。

    其次，LXTerminal 並非真的好，最重要的 Process Sharing 也尚未完成，在這前提之下，就算再好充其量也只不過與 Sakura 相同，在多視窗時資源消耗還是很大。

    此外，libvte 本身就無法避免掉許多資源的消耗〔痴肥〕，但因編碼等問題卻是一時之選。在這架構下，如何應用『手段』讓資源壓低是各開發者的挑戰，由各家的 Source Code 實作可看出端昵，而優缺點也可從 Code 中見其真相。

    不用使用太深奧的理論，有個最簡單的方法就可證明各家 Terminal 的好壞，就是請各開 20 個 Terminal 立見高下。

    目前 LXTerminal 只是為了解決在 EeePC + LXDE 上沒有好用的 Terminal ，因此而寫出來的小 Project，但一切還只是開發階段，在 Process Sharing 還沒完成前根本只是堪用罷了。

    LXTerminal 最終目標會考慮使用 rxvt 再加入 Unicode 等支援，畢竟相較之下 rxvt 還是比 VTE 來的輕量許多，不過因目前沒太多時間而暫且擱著。

    回覆刪除
  6. 匿名2008年6月16日 下午5:05

    評論以及宣傳的手法不是以打擊他人來凸顯自己的。因為扣這頂帽子手法很惡劣，如果沒有真相或是其他 term 都默不坑聲，那往後 google 時都會看到這篇打壓它人凸顯自己的論點。

    如果您真心想要評論，應該是提供一個第三者可以複製的測試環境測試方法以及報告，而不是再這邊說，xxx ram 用量肥大，愚蠢，效能及差，反應速度慢芸芸。提供一個『第三者可以複製的測試環境測試方法以及報告』，遠比用情緒化的語言，或貶損人的方式來的強烈以及正確，而且你可以肯定的說明你的測試方法絕對經的起考驗嗎？測試的方法及方向不同，會產出南轅北轍的報告，『了解有關微軟與Linux的事實 Windows伺服器的整體擁有成本更低 作業系統執行效能更卓越！』這就是極佳例證。。有很多東西都是功能以及效能來衡量，小及速度快，已經不再是絕對優勢，不符合功能或需求就是零分，速度再快 RAM 再小也是零分。

    您要真心宣傳，可以強調您所著墨的功能或特性，秀出來寫出來強調出來，畫出未來性，吸引您所想要吸引的族群，讓他們來使用這個工具，回饋正向循環，這也遠比您先踢後自褒來的正確。

    可以的話真心建議您修改這篇 blog ，將貶損收起來，改用數據來左證您的想法，有數據有方法才可以比較分析，公開自己的方法，他人再可以針對問題戳插或是認同。

    lloyd huang

    回覆刪除
  7. 匿名2008年6月16日 下午5:07

    我猜大概是沒去詳細看 evilvte 的 code？不然，應該是不會和 sakura 聯想在一起。

    回覆刪除
  8. Fred Chien2008年6月16日 晚上7:29

    To lloyd huang：
    首先，文中只有指出各家缺點，並提出可改進的機制〔話說這方法也不是我想出來的，可見各大 Terminal Source Code〕。這可能造成的影響，我想也不需我再證明才是。

    此外，文中也有指出 LXTerminal 目前『相同的缺點』且『尚未改進』。更重要的是，我指出的部份缺點和『功能或需求』其實是沒有關係的。那只是一個常見用來壓低 VTE 使用資源的手段。

    還有，請別『斷章取義，頭尾亂接』。講話請講明白，不然 Google 大神也會看到您南轅北轍的『斷章取義』：

    GNOME 為何『肥』？在 LXDE 用 XFCE4 Library 為何『蠢』？沒使用 Process Sharing 的機制會如何？

    別人的本義也並不是您所說的那樣，別以偏蓋全的說他人嘴巴不乾淨，妨礙他人名譽並扣帽子是令人生氣的。

    而且，在文內並未說到 LXTerminal 比較好，只是因為覺得很多 Terminal『不是肥就是慢』，想自己重寫看看，但革命尚未成功，我看不出目前的 Code 有何偉大之處，『凸顯自己』一詞何來之有？

    To LGJ 前輩：
    小弟不才，不敢說研究透徹，但各家 Terminal 多少都將 Source Code 看過了，這應該是最基本的功課，且我不會在沒參考過多數實作的情況下，就做出評斷。相信一向謹慎的您，應該也是會在研究過數家成果後才會評斷才是。

    而 Sakura 的缺點和 Evilvte 完全是如出一徹的，縱使重寫再多東西，只要使用 VTE 的方法一樣，在多視窗時的記憶體用量就會爆增。這也是為什麼有些 Terminal 要用到 Dbus 等方法，來達成 Process Sharing 的實現。

    備註：
    我同意以數據形式來證明論點，但並不同意有人對看不懂的名詞視而不見，然後多加評論，且反而要求我給出數據。

    套句 LGJ 之前所引用的話『有些人有種奇怪的想法-- 認為一些客觀知識的總合即為智慧（林語堂．啼笑皆非）』

    回覆刪除
  9. 匿名2008年6月16日 晚上7:50

    我暫時先把一些「雜音」去除不論。

    重點應該是態度的問題？使用一些較尖銳的用詞時，精準些、緩和些，這樣能讓多數人接受的可能性會增加才對。

    在 evilvte/lilyterm 開始的時候，我就曾提出過 vte 太肥（相對於 lightweight 的要求而言）的問題，當時 eliu 也曾提議過把 libvte 減肥。我會說和 Sakura 不一樣，指的並不是用到 vte。

    但是各個 terminal，他的設計目的並不會一樣，而且一開始實作時和過一段時間改進後也不會是一樣的面目。

    lloyd 的用意應該是很明顯，重點是在：競爭，而不是互批，甲的良藥可能卻是乙的毒藥，這種例子實在是太多了。

    以上參考。

    回覆刪除
  10. Fred Chien2008年6月16日 晚上8:42

    受教。

    回覆刪除
  11. Fred Chien2008年6月17日 上午8:22

    補充一點。

    LXTerminal 的 Process Sharing 機制已經在早上被實作出來，有興趣的人可嘗試 svn 內的最新版本。

    回覆刪除
  12. PCMan2008年6月18日 凌晨3:18

    我個人還是認為，只要是用到 VTE 的
    都應該把 lightweight 字樣從廣告中拿掉
    當然，包括 evilvte 和 lxterminal 在內。
    同類程式資源消耗九成以上都在 VTE 上
    在其他地方東省西省，開一個分頁就回來了。
    所以做這樣的東西，個人認為是很沒有效益的。
    這也是為何我本來也想寫 vte-based 的
    後來取消了 (殘渣還留在 svn 內)
    不管怎麼改，到最後各家消耗的資源還是很接近
    分頁開越多越明顯，省下的部份差異小到可以忽略
    如果不能有革命性的新實做，個人覺得
    用 VTE 在那裡東省一點西省一點，其實真的很沒有意義。

    VTE 要減肥極為困難，除了拿掉多種 backend 之外
    剩下的部份很難再瘦了，否則 i18n 支援可能會不正確
    urxvt 在中文正常，但是在中東語言會怎樣沒人知道
    VTE 作者似乎是那些地區的人，所以支援完整。
    VTE 其實已經做了很多提昇 performance 的技術了
    改善還是很有限，我不覺得改寫 VTE 可以改善多少
    尤其我們並不知道在其他語系下，到底會如何。
    寫 terminal emulator，其實很難的...

    回覆刪除
  13. 匿名2008年6月18日 上午9:53

    evilvte 把 lightweight 拿掉了：
    http://hyperrate.com/topic-view-thread.php?tid=5309

    回覆刪除
  14. PCMan2008年6月18日 下午5:19

    我查過了，urxvt 不支援阿拉伯文等複雜的語言
    也不能支援由右寫到左的語言，所以，不能用。
    可惜，否則 urxvt 還有支援嵌入到其他程式內

    mlterm 支援比較好，不過 code 有點可怕
    看來 VTE 還是不得已當中的選擇....

    回覆刪除
  15. Fred Chien2008年6月18日 晚上7:58

    現在，大家不過都是在 VTE 之下搶空間而已，在可用性不差的前提上，搶最少的 dependency、最少的記憶體浪費、最佳的反應效能。

    唉，以作為一個良好開發環境的目標來說，好的多國語系支援是很重要的呀 :(

    對 VTE 真是又愛又恨。

    回覆刪除
  16. PCMan2008年6月18日 晚上8:14

    我個人比較傾向繼續使用 roxterm，而不是自己重包一個 vte 殼
    另外，效能問題不可能是 roxterm 獨有
    一樣都是 VTE，不可能在繪圖部份有差別
    roxterm 唯一有問題的是 dbus 部份
    而那個可能是 debian 的 bug，因為在其他 distro 沒遇到
    我也沒發現程式碼裡面有什麼異常

    建議不要浪費太多時間在這裡...
    除非你有什麼特別好的新點子。

    另外 user-friendly 在 terminal 我個人不會太看重
    只要可接受即可，畢竟會用 terminal 的 target audience
    多半是 power user。

    以上是個人一點和你看法不同的地方...

    回覆刪除
  17. Fred Chien2008年6月18日 晚上10:37

    我原本是使用 Sakura 和 Lilyterm(忘了是誰推薦了)，後來改用 XFCE-terminal 為了享受那單一 process 的資源節省，後來又聽你的推薦，改用 Roxterm，最後受不了暫時改用 xterm 來開發 LXTerminal。

    經過一連串更換使用和惡夢後，我想每家 Terminal 在我的 EeePC 上都有公平的待遇和測試條件。況且我用 Terminal 最主要是使用 vim，所以，我能接受 Terminal 效能差，但再差也不能讓我在 coding 時感到痛苦。

    決大部份的 Terminal 扣掉記憶體用量問題外，都有可接受的速度，但只有 Roxterm 在我的 EeePC-900 630Hz + Compiz 上回應速度低落，且情況極為嚴重，這問題明顯的是它獨有。經檢查 sourcecode 後，發現這問題不是出在 VTE 上，而應該是他在處理 VTE 的相關問題時，所使用方法所造成的。

    因此，其他 Terminal 並沒有這效能差的問題。不可否認， Roxterm 搞定了很多 VTE 所產生出來的難搞 BUG，只是效能不彰就是了。

    回覆刪除
  18. PCMan2008年6月19日 凌晨12:17

    也許可以 bug report to roxterm's author
    roxterm 是我用過這麼多家比較之後
    覺得 bug 最少的。別人有的問題他幾乎半個都沒有
    而且 performance 問題在我的系統上都沒發生
    所以就像我們之前懷疑的，可能跟 compiz 有關

    目前有支援切換編碼的 vte-based 不多，
    除 gnome-terminal 外大概只有 rox & lily
    roxterm 又有 single instance 支援，並且有完整 config UI

    如果不是你說的問題，這真的是我目前用過最喜歡的 vte-based terminal.
    很希望你說的問題有天他能修好，你可以發 bug report 給作者嗎？

    回覆刪除
  19. Unknown2008年6月25日 上午11:37

    Hi Fred,
    我已經為 Eee PC 打包好了大部份的 lxde 軟體，但是新版的 LXLauncher 遇到問題，就是 gtk 要求比 Eee PC 提供的高（像firefox3的case)，請問有方法可以用回舊版的 gtk 嗎?
    如果能夠告訴我那一個 function 是新 gtk 獨有的也可以，我試試修改。

    回覆刪除
  20. Fred Chien2008年6月27日 凌晨2:38

    據我所知，新版 LXLauncher 因為用到了 cairo ，所以至少就要 GTK+ 2.8 以上版本才能跑了。

    回覆刪除
  21. 匿名2008年10月24日 下午6:35

    請問一下, lxlauncher-0.2要如何才能換background, 原始的source code已經把background那段comment掉了, 是有什麼問題嗎? 謝謝.

    回覆刪除

張貼留言

這個網誌中的熱門文章

有趣的邏輯問題：是誰在說謊

開心的是期中考接近尾聲，而且今天也是我的生日，更開心的是老天爺待我很好，放我一天假沒給我排考。今天，在網路上逛啊逛，看到了一些判斷說謊的邏輯問題，雖然之前就曾看過，但不管再看多少遍都還是覺得很有趣。也想到好幾天沒寫東西了，就貼上來讓大伙一同分享吧！準備好接受考驗了嗎？ Ready? Go! 第一題： A 說B 在說謊，B 說 C 在說謊，C 說 A、B 都在說謊。請問到底誰在說謊？ 第二題： 現在審問四名竊賊嫌疑犯。已知當中有一名是竊賊，還知道這四個人不是誠實就是說謊，請根據他們回答問題的結果中，判斷誰是竊賊。 甲說：『乙沒有偷，是丁偷的。』 乙說：『我沒有偷，是丙偷的。』 丙說：『甲沒有偷，是乙偷的。』 丁說：『我沒有偷。』 解答：一：只有 B 說真話。二：乙是竊賊。
繼續閱讀

Web 技術中的 Session 是什麼？

圖片
很久沒更新了，自從十二月底退伍之後，一直忙著將書完稿給出版社，沒空坐下來好好在 Blog 上寫點東西。沒辦法，在當兵時閒不下來，就答應了出版社的邀約開始寫 Node.js 的書，因此欠下了書的債。還好，如預期的寫完了，預計這一兩個月應該就會上市，還請各界多多捧場！ 會寫這篇文章的原故，是因為在 Facebook 的社群上，有人問起了關於 Session 和 Cookie 相關性的問題。其實，社群的人都很好，有許多熱心的網友願意幫助別人。不過，為了幫忙回答問題，大家七嘴八舌的東說一句西說一句，甚至引起莫明的論戰，實在不是一個好的現象。況且，使用不同語言、有不同技術背景的人，都各自用自己的角度去描述和解說，讓原本就已經不懂的人更有如瞎子摸象，見不到全貌，搞更糊塗了。對發問的人來說，也不知該聽誰的好。 說來湊巧，筆者剛好在剛截稿的 Node.js 書籍中，對 Session 概念也有許多著墨。所以之前稍微在網路上查過，發現鮮少有人提出對 Session 技術的完整說明，而多半是討論 ASP、.Net、Java、PHP 等語言或框架中如何使用 Session，以及一些延伸的特性，以致很多人對 Session 的概念相當片面。因此這次的事件後，一些網友也建議我把在 Facebook 上回應的完整內容，在 Blog 發表記錄下來，讓更多人對 Session 有個比較完整且正確的認識。 本文目標 在 Web 的世界裡，Session 已經是被廣泛使用的一種技術，大多數的 Web 開發者，肯定都能運用自如。在現今的各類 Web 應用程式的開發框架和工具中，Session 也已經被包裝成容易使用的模式，所以本文也就不再多討論 Session 怎麼去使用，而是著重在 Session 的原理和實現上。要知道，無論是使用哪一種語言，這 Session 概念上都是通用的，沒有什麼不一樣。 Session 是什麼？ Session 之所以會存在，是因為 HTTP 為 stateless 的設計，Server 和 Client 不會一直保持連線狀態，也不會有雙方狀態的即時更新，所以，Server 並不知道 Client 的狀態（像是是否已經登入）。因此，後來的網站開發者，採用 Session 這樣的設計來解決這問題。有趣的是，Se
繼續閱讀

淺談 USB 通訊架構之定義（一）

圖片
USB(Universal Serial Bus) 的應用範疇以及價值已經不需要再多做說明，其身影從 HID(Human Interface Device)、隨身碟（USB Stick、Flash drive、Pen drive）到各種類比式或非連續訊號接收器（如： Webcam、Microphone、DVB Receiver），更進一步可以講到各種通訊裝置或外接設備，甚至是取代和模擬舊式通訊傳輸線（Serial Port）。USB 所有的 Spec 和相關資訊 ，可參考 http://www.usb.org/ 。 USB 整體運作模式 一般來說 USB 的通訊結構有如 Server/Client，以 PC 上的情形為例，位於主機上的 USB 裝置稱為『USB Host』，我們可以在上面外接上數個裝置（與 USB Host 相連的裝置通常被稱為 USB Device 或 USB Client）。 底層上，『Host 負責主導整個 USB 結構的通訊』，它會輪詢所有的 USB Deivce 以檢查是否有裝置需要傳送資料，所有 USB Device 都必需要等待 Host 的命令，唯有 Host 同意時，USB Device 才可以開始傳送資料。 Host 的行為通常是由 USB Host Controller 在做控制，其控制器是一組控制晶片，而對於現代 PC ，USB Host Controller 的晶片通常都被 Layout 在主機板上，以 PCI Bus 的形式存在供作業系統控制，我們可以使用 lspci 看到它的存在： 00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 03) 00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 03) 00:1a.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 (rev 03) 00:1a.7 USB Controller: Intel Corporati
繼續閱讀

淺談 USB 通訊架構之定義（二）

圖片
之前『 淺談 USB 通訊架構之定義（一） 』已經提過 USB 大致上的概念和一些特性，以及如何從 Linux 上去嘗試驗證 USB Device 上的 Information，但還尚未談及 USB Device 是如何與 USB Host 做溝通。而且，初始化的過程也很重要，該過程會讓一個 USB Device 描述自己的『模式(Configuration)』和『介面(Interface)』以及更多配置上的關鍵訊息。雖然這些初始化過程和定義繁雜，但是拜 OS 優良的包裝所賜，一般驅動程式都可以假設已知或是透過簡單的 API 去取得這些資訊以進行開發，因為大多數初始化動作會自動由 OS Kernel 和 Firmware 所完成。 簡單的 USB Device 初始化流程 插上 USB 裝置 Host 請 裝置 報告 『 裝置 描述資訊 (Device Descriptors )』 （此過程又稱為 Enumeration ） 由 Device Descriptors 得知 『 模式的數量 (bNumConfigurations) 』 Host 請 裝置 回報 『 模式的描述資訊( Configuration Descriptors) 』 由 Configuration Descriptors 得知 『 介面的數量( bNumInterfaces ) 』 Host 請 裝置 回報 『 介面 的描述資訊( Interface Descriptors) 』 由 Interface Descriptors 得知 『 端點的數量( bNumEndpoints ) 』 Host 請 裝置 回報 『 端點 的描述資訊( Endpoint Descriptors) 』 由 Endpoint Descriptors 得知 『 該端點的 資料傳輸模式( bmAttributes ) 』等訊息 等待驅動程式進行後續處理 整個 USB Device 的描述結構可以圖表示： 當然，若不是 USB Device 設計者或是 USB Host Controller 晶片的 Firmware/Driver 開發人員，可以不用知道這麼多過程細節，因為無論是 Linux 還是其他作業系統，它們都會將這些最低階的過程包裝起來，等著驅動程式去使用，而 Linux Kernel 上負責此任務的就被稱為
繼續閱讀

Reverse SSH Tunnel 反向打洞實錄

近來經手了幾個案子，其目標都是設計一台做特定用途的系統，但往往這台機器都會被鎖在防火牆後面，甚至不會連上網際網路，是完全封閉的環境。每當接近結案，將系統交到客戶手中以做最後的壓力測試時，便是痛苦的開始。怎麼說呢？因為當面對最後的大量測試，各種大大小小的臭蟲(Bugs)就會原形畢露，一一浮上臺面。而每次問題發生，便要千里迢迢趕到客戶那了解情況、解決問題。如果問題不大倒還好，一旦問題嚴重，被客戶關到三更半夜也是常有的事，更誇張的還必須每天都去報到。所以，為避免車程來回的時間和人力浪費，是否有可以遠端連線做處理呢？便思考起這問題。 雖然這些機器通常都不會有真實 IP，客戶也不會為了我們特別請 MIS 去開啟 NAT 或防火牆，但還好 SSH 提供了反向(Reverse)的機制讓我們可以連進去。其做法就是讓在客戶那的系統，透過 SSH 先連回我們自家有真實 IP 的主機，然後建立反向的通道即可。如此，我們便可從自家的主機，從 SSH 連回放在客戶那的系統。 實際的操作步驟： # 首先，在客戶那理的機器下指令連回我們自己的 Server，並設定自己 Server 上的 12345 port 會對應到幾器上的 SSH port ssh -NfR 12345:localhost:22 fred@myhost.com # 然後在 myhost 的機器上連自己的 12345 port，就可以連回在客戶那的機器 ssh localhost -p 12345 後記 可以將建立 Reverse SSH tunnel 的命令設定在開機後執行，並且透過設定 ssh config 讓斷線時自動重連，如此就可以確保 SSH 連線不會中斷。此外，若是客戶端那的機器是處於完全無法對外連線的環境，則可以考慮使用 3G 網卡，並將網卡暫時借放於客戶那，然後等結案後再取回，雖然 3G 通訊月租不便宜，但和經常來回的通勤費和時間花費相比，可滑算多了。
繼續閱讀