Home » Posts tagged "update"

Python 2 的 EoL 日期將會是 2020 年年初

在「Python 2 EOL will be 2020-01-01」這邊看到的,文章標題的連結是 mailing list 上的內容:「[Python-Dev] Python 2.7 -- bugfix or security before EOL?」。

Guido van Rossum (Python 的發明人) 在回覆關於「Python Developer’s Guide — Python Developer's Guide」上面的資訊時的說明... 大約還有一年九個多月的時間。

然後發現原來 Python 在 release 時是會發佈 PEP 的,像是「PEP 373 -- Python 2.7 Release Schedule」這樣的資訊。其他版本可以在索引頁「PEP 0 -- Index of Python Enhancement Proposals (PEPs) | Python.org」翻到。

EnterpriseDB 打算推出的 zheap,想要解 VACUUM 問題...

前天被問到「DO or UNDO - there is no VACUUM」這篇,回家後仔細看一看再翻了一些資料,看起來是要往 InnoDB 的解法靠...

PostgreSQL 與 InnoDB 都是透過 MVCC 的概念實做 transaction 之間的互動,但兩者實際的作法不太一樣。其中帶來一個明顯的差異就是 PostgreSQL 需要 VACUUM。這點在同一篇作者八年前 (2011) 的文章就有提過兩者的差異以及優缺點:「MySQL vs. PostgreSQL, Part 2: VACUUM vs. Purge」。

UPDATE 時,InnoDB 會把新資料寫到表格內,然後把可能會被 rollback 的舊資料放到表格外:

In InnoDB, only the most recent version of an updated row is retained in the table itself. Old versions of updated rows are moved to the rollback segment, while deleted row versions are left in place and marked for future cleanup. Thus, purge must get rid of any deleted rows from the table itself, and clear out any old versions of updated rows from the rollback segment.

而被 DELETE 清除的資料則是由 purge thread 處理:

All the information necessary to find the deleted records that might need to be purged is also written to the rollback segment, so it's quite easy to find the rows that need to be cleaned out; and the old versions of the updated records are all in the rollback segment itself, so those are easy to find, too.

所以可以在 InnoDB 看到 purge thread 相關的設定:「MySQL :: MySQL 5.7 Reference Manual :: 14.6.11 Configuring InnoDB Purge Scheduling」,負責處理這些東西。

而在 PostgreSQL 的作法則是反過來,舊的資料放在原來地方,新資料另外存:

PostgreSQL takes a completely different approach. There is no rollback tablespace, or anything similar. When a row is updated, the old version is left in place; the new version is simply written into the table along with it.


Lacking a centralized record of what must be purged, PostgreSQL's VACUUM has historically needed to scan the entire table to look for records that might require cleanup.

這也使得 PostgreSQL 裡需要 autovacuum 之類的程序去掃,或是手動跑 vacuum。而在去年 (2017) 的文章裡也有提到目前還是類似的情況:「MVCC and VACUUM」。

而在今年 (2018) 的文章裡,EnterpriseDB 就提出了 zheap 的想法,在 UPDATE 時寫到 table 裡,把可能被 rollback 的資料放到 undo log 裡。其實就是把 InnoDB 那套方法拿過來用,只是整篇都沒提到而已 XD:

That brings me to the design which EnterpriseDB is proposing. We are working to build a new table storage format for PostgreSQL, which we’re calling zheap. In a zheap, whenever possible, we handle an UPDATE by moving the old row version to an undo log, and putting the new row version in the place previously occupied by the old one. If the transaction aborts, we retrieve the old row version from undo and put it back in the original location; if a concurrent transaction needs to see the old row version, it can find it in undo. Of course, this doesn’t work when the block is full and the row is getting wider, and there are some other problem cases as well, but it covers many useful cases. In the typical case, therefore, even bulk updates do not force a zheap to grow. Instead, the undo grows. When a transaction commits, all row versions that will become dead are in the undo, not the zheap.

不過馬上就會想到問題,如果要改善問題,不是個找地方記錄哪些位置要回收就好了嗎?順便改變方法是為了避免 fragment 嗎?


Ubuntu 開始更新 Kernel 了...

這波 CPU 安全問題,UbuntuLinux Kernel 的更新計畫 (workaround patch) 放在「Information Leak via speculative execution side channel attacks (CVE-2017-5715, CVE-2017-5753, CVE-2017-5754 aka Spectre and Meltdown)」這邊。

不是所有版本的 kernel 都有更新,像是我之前跑 4.10 發現這次沒在清單內,就換成 linux-image-generic-hwe-16.04-edge 了... 換完後需要再裝 linux-headers-generic-hwe-16.04-edge,然後把舊的 kernel 都清乾淨,最後 nvidia-387 需要重新編過。



前幾天提到 Apple 在新版 iOS 上搞出的電池問題:「iPhone 換電池恢復效能的事情傳到 Geekbench 後...」,結果看起來是 PR 部門整個加班處理 XDDD

台灣版的公告在「致廣大顧客關於 iPhone 電池與效能的說明」這邊可以看到,英文版的則是在「A Message to Our Customers about iPhone Batteries and Performance」這邊。


  • Apple 為需要更換電池的 iPhone 6 或後續機種使用者,降低更換已過保固期的 iPhone 電池價格,從 NT$2,590 降為 NT$890,降幅為 NT$1,700。自 2018 年 1 月底至 12 月,全球同步進行。詳細優惠資訊將在近期於 apple.com/tw 公布。
  • 在 2018 年初,我們將發布一項 iOS 軟體更新,其中的新功能可為使用者更清楚顯示 iPhone 電池的健康狀態,讓他們可以自己看到電池的狀態是否影響效能。
  • Apple is reducing the price of an out-of-warranty iPhone battery replacement by $50 — from $79 to $29 — for anyone with an iPhone 6 or later whose battery needs to be replaced, starting in late January and available worldwide through December 2018. Details will be provided soon on apple.com.
  • Early in 2018, we will issue an iOS software update with new features that give users more visibility into the health of their iPhone’s battery, so they can see for themselves if its condition is affecting performance.

所以總算是能在 iPhone 上面直接看到電池的情況了...

AWS 的 Patch Manager 支援 Linux

在「Amazon EC2 Systems Manager Patch Manager now supports Linux」這邊 AWS 宣佈了 Patch Manager 支援 Linux 的消息。


  • Amazon Linux 2014.03 and later (2015.03 and later for 64-bit)
  • Ubuntu Server 16.04 LTS, 14.04 LTS, and 12.04 LTS
  • RHEL 6.5 and later (7.x and later for 64-Bit)

連已經超過 LTS 支援期的 Ubuntu 12.04 都支援了... 不過 CentOS 看起來沒順便支援?

可以設計一些規定 (與組織內規範相關的,像是 approval process) 讓 Patch Manager 決定要怎麼佈:


iOS 透過無線網路的 RCE...

在「About the security content of iOS 10.3.1」這邊的說明:

Available for: iPhone 5 and later, iPad 4th generation and later, iPod touch 6th generation and later
Impact: An attacker within range may be able to execute arbitrary code on the Wi-Fi chip
Description: A stack buffer overflow was addressed through improved input validation.
CVE-2017-6975: Gal Beniamini of Google Project Zero


cURL 接下來的安全性更新...

cURL 的維護老大放話要大家注意接下來的安全性更新:「An alert on the upcoming 7.51.0 release」。

最少 11 個安全性更新:

This release will bundle no less than _eleven_ security advisories and their associated fixes (unless we get more reported in the time we have left).

由於這些 security issue 的特性,會採取不公開的 branch 修正再 merge 回來,再加上這麼大的數量,對於穩定性的衝擊是未知的:

Merging eleven previously non-disclosed branches into master just before a release is not ideal but done so to minimize the security impact on existing users when the problems get known.

所以目前的規劃是會在 release 的 48 個小時前公開 (希望藉由這封信讓有能力的人一起集中來看),藉此來降低衝擊:

My plan is to merge them all into master and push around 48 hours before release, watch the autobuilds closesly, have a few extra coverity scans done and then fix up what's found before the release.

這安全更新的數量好像有點多 orz

FreeBSD 11.0 重新發行...

本來已經發行的 FreeBSD 11.0,因為最近的安全性問題 (應該是講 OpenSSL?),決定不以 security update 的方式更新,而是直接發新版了:「[REVISED] [HEADS-UP] 11.0-RELEASE status update」。

Although the FreeBSD 11.0-RELEASE has not yet been officially announced, many have found images on the Project FTP mirrors.

However, please be aware the final 11.0-RELEASE will be rebuilt and republished on the Project mirrors as a result of a few last-minute security fixes we feel are imperative to include in the final release.

我以為應該是發 11.0.1,然後把架上的 11.0 拿掉...

Adobe 居然決定加碼投入資源更新 Linux 上 NPAPI 版的 Flash (也就是舊版 API)

在「Beta News – Flash Player NPAPI for Linux」這邊看到 Adobe 要投入資源處理 LinuxNPAPI 版的 Flash Player...

先前 Linux 下是 NPAPI 與 PPAPI 兩個版本都有 Flash Player,但是 NPAPI 維持在 11.2,只做安全性更新:

Linux users have access to both NPAPI and PPAPI versions of Flash Player. However, for the last four years, the NPAPI version has been held at 11.2 and regularly updated with only security fixes while the PPAPI version (used in Chrome and Chromium based browsers), is in line with the standard Windows and Mac releases.


Today we are updating the beta channel with Linux NPAPI Flash Player by moving it forward and in sync with the modern release branch (currently version 23). We have done this significant change to improve security and provide additional mitigation to the Linux community.

Flash Player 你趕快退場啊啊啊...