Chrome 與 Chrome OS 最近不會更新新功能

這邊看到的消息,ChromeChrome OS 會避免在最近推出新功能,以維持軟體的穩定性,最近更新的主力會放在安全性上:「Google halts upcoming releases of Chrome and Chrome OS to keep things stable for everyone working from home」。

報導引用自 Twitter 上的宣佈:

呃,突然想到 Windows 的更新情況...

Python 2 的後續支援

雖然 2020/01/01 開始 Python 2 就沒有官方支援了 (翻了一下資料發現「Python 2 series to be retired by April 2020」這篇,官方好像延到四月了...),不過剛剛看到這則新聞,裡面提到了商業支援:「Snakes on a wane: Python 2 development is finally frozen in time, version 3 slithers on」。

在最後一段:

Those catering to corporate clients intend to continue support Python 2.7 for a while. In October, Red Hat said it will stop supporting Python 2.7 in RHEL 8 come June 2024.

不確定這些 patch 會不會也移植到 CentOS 上,如果會的話,至少有一個地方可以讓你多四年掙扎,感覺上可以用 container 生一個獨立的環境...

另外 Ubuntu 這邊的 LTS 不知道有什麼方案,已知 20.04 的目標是要移除掉,但 16.04 與 18.04 裡的 Python 2 如果有問題時,不知道會不會收 patch...

再來就是 pyenv 了,翻了一下目前的情況,好像就是放著,不知道會有什麼方案搬出來...

Windows 7 終止支援

Windows 7 跳出畫面才發現 2020/01/14 終止支援,官方的說明可以在「Windows 7 support ended on January 14, 2020」這邊看到。維基百科上也查的到資料:

Mainstream support ended on January 13, 2015.
Extended support ended on January 14, 2020.
Extended Security Updates paid in yearly installments for 1, 2, or 3 years (or free for Windows Virtual Desktop users) until at most January 10, 2023 only for Professional and Enterprise volume licensed editions.

大量授權用戶可以採購延伸授權,另外 Windows Virtual Desktop (跑在 Azure 上的版本) 則是免費提供。雖然沒有更新,但我猜可能還是會有人把 patch 整理出來讓使用者裝吧...

在 x86-64 上跑 Raspberry Pi 的 OS

看到「dockerpi」這個專案,讓你可以在 x86-64 上模擬 Raspberry Pi 環境跑 Raspbian

然後整包是先透過 Docker 產出一個獨立環境,然後裡面跑 QEMU 模擬 ARM 的環境,接下來再跑 Raspbian:

A full ARM environment is created by using Docker to bootstrap a QEMU virtual machine. The Docker QEMU process virtualises a machine with a single core ARM11 CPU and 256MB RAM, just like the Raspberry Pi. The official Raspbian image is mounted and booted along with a modified QEMU compatible kernel.

這馬上讓人想到 Inception 啊 XDDD

Anyway,這個方法對於想玩玩的人可以省不少功夫,是個有趣的專案就是了...

macOS 打算移除 Perl/Python/Ruby

從 beta 版的 release note 可以看到 macOS 打算在 10.15 移除 PerlPythonRuby:「macOS 10.15 Beta Release Notes」。

Scripting language runtimes such as Python, Ruby, and Perl are included in macOS for compatibility with legacy software. Future versions of macOS won’t include scripting language runtimes by default, and might require you to install additional packages. If your software depends on scripting languages, it’s recommended that you bundle the runtime within the app. (49764202)

看起來會另外包一份出來... 不過這樣內建的工具就少了些,雖然 shell script 是 turing machine... :o

修正 Mac 外接螢幕的 Underscan 問題

公司的 MacBook Pro (13-inch, 2017, Two Thunderbolt 3 ports) 透過 HDMI 接 Dell P2419H 一直都有 Underscan 的問題:


出自「About overscan and underscan on your Mac, Apple TV, or other display

本來想透過 Underscan slide 修改 (像是下面這張圖),但發現系統內沒有 Underscan slide。


出自「About overscan and underscan on your Mac, Apple TV, or other display

找了不少文章後後來是在「Fixing Issues with Overscan/Underscan(Black Borders) on macOS」這篇的 comment 看到解法:

Ran into this same underscan problem with black borders showing up on my new Dell 24-inch Ultrasharp U2415 connected to a 2013 Macbook Air running High Sierra, and after hours of looking into the problem the fix turned out to be super simple:

Just restart in Safe Mode.

That’s it. Restart your Mac in Safe Mode (restart, hold down the Shift key after the Apple BONG sounds, then restart normally once again for good measure. I don’t know what this clears or resets but it worked for me. No more letterboxing or black borders with the native 1920×1200 resolution selected.

So maybe something to try first for anyone coming across this post.

照著重開進 Safe mode 後再開回一般模式就正常了 (what???),先記錄起來,讓我之後遇到時可以搜尋到自己的文章...

只透過 SSH 重灌系統的 takeover.sh

看到 marcan/takeover.sh 這個專案:

Wipe and reinstall a running Linux system via SSH, without rebooting. You know you want to.

還蠻有趣的專案 (實用性質應該不高,主要是展示可行性),程式很短,就一個 C program 以及一個 shell script,但裡面用到很多外部工具 (像是 BusyBox 的執行檔),作者建議有興趣的人可以先用 virtual machine 玩...

這個專案讓我想到更複雜的 Depenguinator,把 Linux 灌成 FreeBSD 的專案,不過這個專案也已經很久沒更新了...

PostgreSQL 對 fsync() 的修正

上次寫了「PostgreSQL 對 fsync() 的行為傷腦筋...」提到 fsync() 有些地方是與開發者預期不同的問題,但後面忘記跟進度...

剛剛看到 Percona 的人寫了「PostgreSQL fsync Failure Fixed – Minor Versions Released Feb 14, 2019」這篇才發現在 2/14 就出了對應的更新,從 release notes 也可以看到:

By default, panic instead of retrying after fsync() failure, to avoid possible data corruption (Craig Ringer, Thomas Munro)

Some popular operating systems discard kernel data buffers when unable to write them out, reporting this as fsync() failure. If we reissue the fsync() request it will succeed, but in fact the data has been lost, so continuing risks database corruption. By raising a panic condition instead, we can replay from WAL, which may contain the only remaining copy of the data in such a situation. While this is surely ugly and inefficient, there are few alternatives, and fortunately the case happens very rarely.

A new server parameter data_sync_retry has been added to control this; if you are certain that your kernel does not discard dirty data buffers in such scenarios, you can set data_sync_retry to on to restore the old behavior.

現在的 workaround 是遇到 fsync() 失敗時為了避免 data corruption,會直接 panic 讓整個 PostgreSQL 從 WAL replay 記錄,也代表 HA 機制 (如果有設計的話) 有機會因為這個原因被觸發...

不過也另外設計了 data_sync_retry,讓 PostgreSQL 的管理者可以硬把這個 panic 行為關掉,改讓 PostgreSQL 重新試著 fsync(),這應該是在之後 kernel 有修改時會用到...

PostgreSQL 對 fsync() 的行為傷腦筋...

FOSDEM 2019 上的演講,討論 PostgreSQL 在確保 ACID 特性中的 Durability 時遇到 fsync() 的行為跟預想的不一樣 (主要是當 fsync() 失敗的行為):「PostgreSQL vs. fsync」。

在「PostgreSQL vs. fsync. How is it possible that PostgreSQL used fsync incorrectly for 20 years, and what we'll do about it.」這邊的 Q&A 形式的訪談有快速描述了短期的計畫與長期的想法:

The short-term solution is ensuring that we detect fsync errors reliably at least on sufficiently recent kernels (since 4.13). On older kernels we can’t do much better, unfortunately.

The long-term solution is still being discussed in the community, but it’s hard to say how we could keep relying on buffered I/O in the future. So we may end up with direct I/O, but that’s a pretty significant change and is likely going to be a multi-year project.

MySQL 這邊則是以 O_DIRECT 為主的世界,受到的影響就小很多了...

沒有 Google 專屬套件的 Android

剛剛在「How to Android without Google」這邊的文章裡看到「How to Android without Google [easy way]」這篇指南,說明如何弄出一個沒有 Google 專屬套件的 Android 環境。

主要是 LineageOS 當作底層基礎 (作業系統),然後用 microG 提供 API 相容層,並且用 F-Droid 安裝 Open Source 軟體。

裡面有兩個方案以前沒看過,一個是 XPosedFramework,提供框架讓使用者有更強的控制力,更完整的說明可以參考「Xposed Framework + App Settings 為每個 App 設定不同的運行模式」這篇。

另外一個是 Yalp Store,當軟體只在 Google Play 平台上提供安裝的時候,就需要透過這個套件了 XD