在 Windows 10 下面執行 Wine

試著在 Windows 10 下跑 Wine,結果文章作者發現意外的簡單:「Wine on Windows 10. It works.」。

實際上大多數的事情是透過 Windows 10 的 WSL (Windows Subsystem for Linux) 所疊出來的,可以從這步看到:

3. Open the Microsoft Store, install Ubuntu. (This is basically what WSL was created to run.) I installed "Ubuntu 18.04 LTS". Open Ubuntu, and you'll see a bash terminal.

這是作者的成果:

還是有些限制 (像是目前還 32 bits 程式還要等之後的 WSL 支援),但比起早年得自己從頭搞起來簡單不少 (而且問題不少),算是完成作者的悲怨?

連安裝 Windows 95 都可以 Speedrun...

看到「Speedrunning Windows 95」這篇,連裝 Windows 95 都可以有 speedrun:

Now, there’s a world record speedrun, installing Windows 95B in just 1 minute 10.9 seconds.

可以看到是在 VirtualBox 裡面裝的,這樣看起來也跟電腦速度有關... (把所有東西都塞到 memory 裡面?)

用 ESP8266 模擬 PC-XT...

看到拿 ESP8266 模擬 PC-XT,是個懷古時間:「IBM PC-XT Emulator on an ESP8266」。

現在小板子的 CPU 跟記憶體都比三十年前的桌機還要大了,直接在上面跑模擬器就算慢一點也已經不是問題了... 直接上麵包板接起來跑:

然後也可以跑 Windows 3.0:

純粹 hacking 的專案 XD

Windows 上的 Chrome 改用 Clang 編譯

這應該是上個禮拜蠻熱鬧的一件事情 (i.e. 很多人看熱鬧 XD),就是 Google ChromeVisual C++ 改成用 Clang 編譯:「Clang is now used to build Chrome for Windows」。

文章裡推敲效能應該不是主要的因素,因為在不同項目測試下各有千秋,而且差距都不大:

We conducted extensive A/B testing of performance. Performance telemetry numbers are about the same for MSVC-built and clang-built Chrome – some metrics get better, some get worse, but all of them are within 5% of each other.

後面有猜測換過去的原因,可以看出因為 open source 加上 Google Chrome 團隊有強大的技術能力下,用 open source 軟體可以對 compiler 大量客製化各種功能,另外也是因為一個 compiler 就可以吃多個平台,可以省下一些跨平台的力氣 (像是相容性語法)。

而 Visual C++ 在商業支援與文件兩方面比較好的優勢,在這個情況下就顯得不是那麼重要了...

在 TeX 上輸出圍棋棋譜的套件 psgo_emitter

忘記是在哪邊看到 avysk/psgo_emitter 這個套件,提供 TeX 語法輸出成圍棋棋盤的圖示,不過說明裡說只支援 Windows 平台:

psgo_emitter is a (Windows) console utility to create go diagrams for go life-and-death problems (tsumego).

可以只輸出角部,像是這段語法:

    \begin{psgopartialboard}{(1,1)(8,6)}
            \stone{black}{b}{3}
            \stone{black}{d}{3}
            \stone{black}{b}{4}
            \stone{white}{d}{5}
            \stone{white}{g}{2}
            \stone{black}{d}{2}
            \stone{white}{b}{5}
            \stone{white}{c}{4}
            \stone{white}{e}{4}
            \stone{white}{e}{3}
            \stone{white}{e}{2}
            \stone{black}{e}{1}
    \end{psgopartialboard}

會輸出這樣的圖:

另外也可以把手順放進去:

    \begin{psgopartialboard}{(1,1)(8,6)}
            \stone{black}{b}{3}
            \stone[\marklb{1}]{black}{a}{2}
            \stone{black}{d}{3}
            \stone{black}{b}{4}
            \stone[\marklb{8}]{white}{f}{1}
            \stone[\marklb{6}]{white}{d}{1}
            \stone{white}{e}{2}
            \stone{white}{g}{2}
            \stone{black}{d}{2}
            \stone{white}{b}{5}
            \stone[\marklb{7}]{black}{b}{2}
            \stone[\marklb{9}]{black}{a}{1}
            \stone{white}{c}{4}
            \stone[\marklb{4}]{white}{c}{2}
            \stone{white}{e}{4}
            \stone[\marklb{5}]{black}{c}{3}
            \stone{white}{e}{3}
            \stone[\marklb{2}]{white}{b}{1}
            \stone{white}{d}{5}
            \stone[\marklb{3}]{black}{a}{4}
            \stone{black}{e}{1}
    \end{psgopartialboard}

就會輸出:

套件還很新,不知道之後會發展成什麼樣子...

Microsoft 的 TTD 與 Mozilla 的 RR

也是個在瀏覽器 tab 上放了一陣子的連結... 先前看到 MicrosoftTime Travel Debugger (TTD),可以錄下程式執行的狀態,然後回放與搜尋:「Thoughts On Microsoft's Time-Travel Debugger」,另外有 CppCon 2017 上的影片,在 YouTube 上:

另外 Mozilla 也有類似的工具,叫做 rr (在影片開頭就有人問類似的問題 XD),程式碼在 GitHub 上:「mozilla/rr」。

而 TTD 與 rr 兩者最大的差異當然是平台支援的情況:

The most important and obvious difference between TTD and rr is that TTD is for Windows and rr is for Linux (though a few crazy people have had success debugging Windows applications in Wine under rr).

但另外一個也很重要的差異是 TTD 支援完整的 multi-threading,這對於現代的程式來說還蠻常見的:

TTD supports recording of multiple threads in parallel, while rr is limited to a single core.

當然,更完整的錄影也是要付出效能代價的:

On the other hand, per-thread recording overhead seems to be much higher in TTD than in rr. It's hard to make a direct comparison, but a simple "start Firefox, display mozilla.org, shut down" test run on similar hardware takes about 250 seconds under TTD and 26 seconds under rr.

不過有需要的時候應該會很方便?工具總是愈多愈好...

Windows 10 將支援 AF_UNIX (Unix Socket)

在「Unix sockets come to Windows」這邊看到微軟的說明文「AF_UNIX comes to Windows」,Windows 10 將要引入 AF_UNIX 了:

Beginning in Insider Build 17063, you’ll be able to use the unix socket (AF_UNIX) address family on Windows to communicate between Win32 processes. Unix sockets allow inter-process communication (IPC) between processes on the same machine.

所以這讓跨 process 溝通的方式又多了一種,而 Unix 的程式如果要移植到 Windows 上,至少這塊有相容... (相容性與 bug 還不知道情況 XD)

玩 ReactOS 0.4.7

ReactOS 是個 Open Source 的作業系統,目標是建立一個相容於 Windows 的環境。剛剛看到 ReactOS 0.4.7 釋出的消息,抓下來用虛擬機玩一下,看看目前的進展如何:「ReactOS 0.4.7 released!」。

現在可以比較輕鬆的在 VirtualBox 上安裝 ReactOS 了,雖然會需要自己改一些設定,但比以前已經簡單很多了... 可以參考「VirtualBox - ReactOS Wiki」這邊的說明,大致上有這幾點需要注意:

  • 在選擇的時候使用 Windows 2003 (32bit)。
  • 一定要掛一顆硬碟進去 (要記得確認設成 IDE 界面)。
  • 網路卡用 PCnet-FAST III。

然後在 Application Manager 把 Firefox 45 裝起來了,但是沒辦法更新到目前的 ESR 版本 52,或是目前最新版 57... 應該是還有些東西沒實做 :o

AWS 提供 Windows 上的 Deep Learning AMI

有一些 Windows 上的東西就可以直接開起來跑了:「Announcing New AWS Deep Learning AMI for Microsoft Windows」。

目前支援 2012 R2 與 2016:

Amazon Web Services now offers an AWS Deep Learning AMI for Microsoft Windows Server 2012 R2 and 2016.

然後 driver 與常用的東西都包進去了:

The AMIs also include popular deep learning frameworks such as Apache MXNet, Caffe and Tensorflow, as well as packages that enable easy integration with AWS, including launch configuration tools and many popular AWS libraries and tools. The AMIs come prepackaged with Nvidia CUDA 9, cuDNN 7, and Nvidia 385.54 drivers, and contain the Anaconda platform (supports Python versions 2.7 and 3.5).

Microsoft 與 GitHub 合作,將會把 GVFS 移植到 Linux 與 Mac 上

MicrosoftGitHub 合作將本來只有在 Windows 上可以用的 GVFS 移植到 LinuxMac 上:「Microsoft and GitHub team up to take Git virtual file system to macOS, Linux」。

GVFS 是解決微軟內部自己在用 Git 的痛處,因為微軟的 repository 都... 有... 點... 肥... (畢竟有不少產品發展了很久)。

目前 Git 的操作是卡在 I/O 與 memory cache 的限制上:

Also, Git wasn't designed for a codebase that was so large, either in terms of the number of files and version history for each file, or in terms of sheer size, coming in at more than 300GB. When using standard Git, working with the source repository was unacceptably slow. Common operations (such as checking which files have been modified) would take multiple minutes.

GVFS 的想法是有用到的部份再真的去拉,藉此大幅減少 I/O 需求...