幹壞事是進步最大的原動力
在「The first conformant M1 GPU driver」這邊看到 Mac (M1 系列與 M2 系列) 上的 Asahi Linux 支援 OpenGL ES 3.1 了。
文章裡面有提到，目前 macOS 上沒有業界標準介面可以用：
Unlike ours, the manufacturer’s M1 drivers are unfortunately not conformant for any standard graphics API, whether Vulkan or OpenGL or OpenGL ES. That means that there is no guarantee that applications using the standards will work on your M1/M2 (if you’re not running Linux).
也許有機會會看到有人 backport 回 macOS 上？
Hacker News 上看到 macOS 要提供 DirectX 介面了：「DirectX 12 Support on macOS (twitter.com/andytizer)」，原推是：
Mac gamers have been dreaming about DirectX 12 support on macOS for years, and the open source community toils tirelessly making baby steps. Then Apple just drops a fully complete DX12 translation layer and doesn't even tell us! pic.twitter.com/cs8OxFJ64s
— Andrew Tsai (@Andytizer) June 6, 2023
算是降低遊戲引擎維護的成本？讓開發商更有意願實作？不確定會有什麼效果...
寫個自己看的，順便整理一些簡單的歷史。
一開始可以先看一下 java 跑起來如何：
$ java --version The operation couldn't be completed. Unable to locate a Java Runtime. Please visit http://www.java.com for information on installing Java.
順便一提，這邊的 java 可以用 which java 看到是出自 /usr/bin/java。
然後透過 Homebrew，可以選擇不同的 JDK 套件安裝，在網路上常見的答案是 temurin (adoptopenjdk 的後繼者)：
brew install temurin
這個好處是裝完可以直接用：
$ java --version openjdk 19.0.1 2022-10-18 OpenJDK Runtime Environment Temurin-19.0.1+10 (build 19.0.1+10) OpenJDK 64-Bit Server VM Temurin-19.0.1+10 (build 19.0.1+10, mixed mode)
另外一種是 OpenJDK，裝完後還得補個 symbolic link：
brew install openjdk sudo ln -sfn /opt/homebrew/opt/openjdk/libexec/openjdk.jdk /Library/Java/JavaVirtualMachines/openjdk.jdk
可以看到這個版本的輸出不太一樣：
$ java --version openjdk 19.0.1 2022-10-18 OpenJDK Runtime Environment Homebrew (build 19.0.1) OpenJDK 64-Bit Server VM Homebrew (build 19.0.1, mixed mode, sharing)
然後不管哪種裝法都記得設定 JAVA_HOME：
export JAVA_HOME="$(/usr/libexec/java_home)"
基本上就能動了。
在噗浪上的這篇看到的工具，讓我想起來之前有想要在 Ubuntu + Xfce 上找類似的工具：
在 macOS 上我最常用的就是計算機與匯率換算，另外就是開應用程式。
但是因為沒辦法直接用 super key 啟動 (也稱作 meta key，或是大家更熟悉的微軟鍵)，所以得迂迴設定，先透過 xcape 把左邊的 super key 對應到 Ctrl-Esc 上：
xcape -e 'Super_L=Control_L|Escape'
然後把本來的 Ctrl-Esc 拔掉：
然後這時候用 super key 時就會改抓到 Ctrl-Esc 了：
接下來就可以勾選 extensions 了，這邊勾了幾個：
然後 Python 這邊把 Currency convert 的部份勾起來：
用法是 1 usd to twd 這樣的句子：
這兩天用起來還不錯，之後遇到問題再來調整...
Apple 在 iOS 16、iPadOS 16 與 macOS Ventura 上推出了 Lockdown Mode：「Apple expands industry-leading commitment to protect users from highly targeted mercenary spyware」。
Lockdown Mode 主要是透過降低被攻擊的面積以提昇安全性，依照 Apple 的預想，主要是針對被政府單位盯上的族群：
Apple is previewing a groundbreaking security capability that offers specialized additional protection to users who may be at risk of highly targeted cyberattacks from private companies developing state-sponsored mercenary spyware.
在 Lockdown Mode 下目前列出來的限制：
列出來的這些的確都是之前 0-day 常被拿來打的東西，把攻擊面積縮小的確會有不少幫助。
這應該是業界第一個大咖跳進來做這個 (也就兩個大咖？)，第一次搞未必會完美，但算是個開始，後面應該會有更多的面積被考慮進去...
在 Hacker News 上看到個有趣的 scalability 問題，在 Mac 上的 sprintf() 因為有 lock 造成的 scalability 問題：「Curious lack of sprintf scaling (aras-p.info)」。
作者注意到 Mac 在多 CPU 下 sprintf() 會有 scalability 的問題，要注意到這邊的 Y 軸是對數比例：
用了 std::stringstream << 反而更慢 (作者還酸了一句「Zero cost abstractions」)：
然後用了 Instruments 跑 profiling 找問題，可以看到看起來跟 locale 有關：
一般的情況下應該不會是問題，但如果是需要大量 sprintf() 組字串的人就會比較要注意了。
在「What else can we do?」這段有提到一些解法，包括了 stb_sprintf 當作替代品，以及 {fmt} 作為 iostreams 的替代品，然後另外是利用 to_chars 來解決，如果只是要把數字轉成字串。
算是蠻有趣的 bug hunting 過程，對於開發者來說，一般性的重點還是在 profiling，找到對的問題然後再往下提出解法...
前幾天看到 BetterDummy 這個專案，作者在 M1 上面外接 24" 1440p 的螢幕，但沒辦法啟用 HiDPI，於是就寫了一個軟體來解：
M1 macs tend to have issues with custom resolutions. Notoriously they don't allow sub-4K resolution displays to have HiDPI ("Retina") resolutions even though (for example) a 24" QHD 1440p display would greatly benefit from having an 1920x1080 HiDPI "Retina" mode.
在這之前的解法都有些麻煩，一種是買個 dummy dongle 去騙 macOS，另外是用 mirror 的方式使用：
To fix this issue, some resort to buying a 4K HDMI dummy dongle to fool macOS into thinking that a 4K display is connected and then mirror the contents of this dummy display to their actual monitor in order to have HiDPI resolutions available. Others use the built in screens of their MacBooks to mirror to the external display. These approaches have obvious drawbacks and cannot solve all problems.
作者提供的軟體可以先建立 Dummy Monitor，然後再透過 mirror 掛到實際螢幕上：
不確定用起來如何，但如果之後有需要的話好像可以測試看看...
Hacker News Daily 上看到的工具：「Quickly create and run optimised Windows, macOS and Linux desktop virtual machines.」，對應的討論在「Quickemu: Quickly create and run optimised Win-10,11/macOS/Linux on Linux (github.com/wimpysworld)」這邊可以看到，可以減少自己要設定一堆 QEMU 參數。
雖然專案是支援多系統，但其實 Microsoft Windows 與 Linux 的部份在其他虛擬軟體都很簡單 (像是用 VirtaulBox)，大家馬上會注意到的重點還是 macOS 的部份，如果有自己弄過就會知道這東西有夠難裝的，而且跨版本有不同的安裝方式...
目前 Quickemu 支援四個版本：
Supported macOS releases:
- High Sierra
- Mojave
- Catalina (Recommended)
- Big Sur
然後可以看到幾乎所有目前能支援的功能都有設定上去了，包括 VirtIO 與 USB 的部份。
然後一些經典的問題，像是 Big Sur 的音源問題還是沒解：
Full Duplex audio works on macOS High Sierra, Mojave and Catalina.
- macOS Big Sur has no audio at all.
在 Hacker News 的討論串裡面有提到有很多地方沒有檢查，這會是風險：
While I appreciate the effort, and the code is very readable. I just want to give a friendly warning that these shell scripts just download random stuff from the internet and run this random stuff without checking any integrity/signature.
下面的討論另外看到個冷知識，關於蘋果故意走 HTTP 下載 recovery image 是因為 HTTPS 太複雜，在 UEFI firmware 裡面實做容易產生被攻擊的點，所以決定自己透過其他機制確認正確性：
Apple Internet recoveryOS images are served over plain http, on purpose. The macrecovery.py script used by Quickemu uses http¹, though the server supports https.
https://support.apple.com/guide/security/recoveryos-and-diagnostics-environments-sec2512a0c09/web
> When the internet recovery and diagnostic modes were added to Mac computers in 2011, it was decided that it would be better to use the simpler HTTP transport, and handle content authentication using the chunklist mechanism, rather than implement the more complicated HTTPS functionality in the UEFI firmware, and thus increase the firmwareʼs attack surface.
[edit] Added macrecovery.py info
另外為了避免直接在 shell script 裡面出現「神秘字串」，可以看到特別的寫法 XDDD
Took a little while to find the magic words in there: https://github.com/wimpysworld/quickemu/blob/af26f41440d63a069045660fad860c797011310a/quickemu#L351
可以想到一些用途，像是在機房裡面跑 CI 的 worker，但要注意這個搞法不符合蘋果的 EULA，現在不抓不代表以後也不會有事，請自己謹慎評估...
然後往 ARM-based 架構後應該門檻就更高了，現在還有 Intel-based 的環境可以用加減用...
Dropbox 也要搞自己的密碼管理器 Dropbox Passwords：「Dropbox Passwords coming soon for all users」。
看起來只要是 Dropbox 的付費方案就可以無限使用，而免費版的則是 50 組。從下載頁看起來目前在 PC 上只支援 Microsoft Windows 與 macOS，不支援 Linux：
Come back to this page on a PC with Windows 10 or a Mac with at least macOS Sierra 10.12 to get the Passwords desktop app.
How do I use the Android and iPhone password manager?
Once you sign in to the Passwords app, it automatically fills in your usernames and passwords so you can access frequently used apps and websites on your mobile device.
從示意圖看起來有整合瀏覽器，而加密技術的部份沒有講太多，只說是 zero-knowledge encryption，先觀望看看...
前幾天在 Hacker News 上看到 Vimac 這個專案，程式碼在 GitHub 的 dexterleng/vimac 上可以看到，而 Hacker News 上的討論則是在「Show HN: Vimac – Productive macOS keyboard-driven navigation (vimacapp.com)」這邊，因為是作者發表的，所以下面也有一些作者的回應。
作者是受到瀏覽器上 Vimium 啟發，利用 macOS 的 Accessibiltiy API 實做類似的想法，讓使用者可以使用鍵盤操作 (所以會需要授權開啟 Accessibility API)。
官方預設啟動 Hint Mode 的快速鍵是 Ctrl-Space，但這對中文使用者來說剛好卡到，所以我把他改成 Option-Space 了，按下去後畫面上會將可以點選的地方都加上快速鍵資訊，像是官方提供的樣式：
另外一個重點是捲動的功能，不過我目前還用的不多，不知道好不好用...