Tag: standard

GCP 提供每個區域的 Standard Tier Networking 每個月 200GB 的免費頻寬

GCP 提供每個區域 Standard Tier Networking 每個月有 200GB 的免費頻寬：「Announcing 200 GB free Standard Tier internet data transfer per month」。

這類優惠應該是要給練習或是試用的人用的，吸引他們放一些量上來...

另外雖然是每個區域都有 200GB/mo 的 free bandwidth，但通常也只會用一個或兩個區域，以台灣的 asia-east1 來說，如果有量在上面跑的話，省下來的會是 $0.07/GB 這個部分，大概就是 $14/mo 左右？

strlcpy() 與 strlcat() 被加入 glibc

Hacker News 上看到「Strlcpy and strlcat added to glibc 2.38 (sourceware.org)」這個，印象中極度排斥 strlcpy 與 strlcat 的 glibc 要包進去了。

主要的原因在原始的 commit log 裡面有提到，是因為 POSIX 標準要放入這兩個 function 了：

These functions are about to be added to POSIX, under Austin Group issue 986.

找了一下提到的 Austin Group issue 986，最後更新是 2022 年，看起來進度不快，但是就是一直推進？

反過來看了一下 Hacker News 上的討論，果然有人把當年 Ulrich Drepper 臭 BSD 流派的信件翻出來：「Re: PATCH: safe string copy and concetation」。

Python 內建的工具

在 Hacker News Daily 上看到「CLI tools hidden in the Python standard library」這個，在講 Python 內建的工具。

其中 python -m calendar 這組看起來還不錯，測了一下可以用 python -m calendar 2024 顯示所有 2024 的月曆，用 python -m calendar 2024 1 則可以顯示 2024 一月單月的月曆。

這操作起來比先前用的 ncal 好多了，先前用 cal 2024 會出現錯誤，因為只有一個參數時他會當作月份，而兩個參數時要把月份放前面，也就是用 cal 1 2024 才能正確顯示。

所以就把本來的 ncal 移除掉，改用 alias 來處理：「Add alias "cal".」。

其他的大多都有習慣的工具了，像是 base64 可以用 openssl base64 處理；而 json.tool 有 jq 可以用。

SQL:2023 的新玩意

Hacker News 上看到「SQL: 2023 is finished: Here is what's new (eisentraut.org)」這篇題到了 SQL:2023 標準的新東西，對應的原文在「SQL:2023 is finished: Here is what's new」這邊。

「UNIQUE null treatment (F292)」讓你可以決定 NULL 到底要不要算 unique，剛好跟之前寫過的「PostgreSQL 15 將可以對透過 UNIQUE 限制 NULL 的唯一性了」要做的事情一樣。

「ORDER BY in grouped table (F868)」則是針對沒有出現在 SELECT 的欄位頁可以 ORDER BY，看了一下說明，主要是在 JOIN 的時候限制住了。很明顯的 workaround 是多加上這個欄位，但就代表會增加傳回的資料量。

「GREATEST and LEAST (T054)」這個因為 MIN() 與 MAX() 已經被 aggregate function 用掉了，所以只好另外取名。

「String padding functions (T055)」與「Multi-character TRIM functions (T056)」是熟悉的語法，各家都有對應的 function 可以做，但這次就放進標準化。

「Optional string types maximum length (T081)」是 VARCHAR 可以不用指定大小了，實務上應該是還好？

「Enhanced cycle mark values (T133)」這編提到的 recursive 真的是每次用每次忘，然後 cycle 這個功能就沒看懂了...

「ANY_VALUE (T626)」看起來可以隨機取出資料，搭配 GROUP BY '' 就不用拿 ORDER BY RAND() 這種髒髒的東西出來了？

「Non-decimal integer literals (T661)」與「Underscores in numeric literals (T662)」都是讓數字更好讀以及操作。

後面講了很多 JSON 功能，看起來是 SQL:2016 有先納入一些，但 SQL:2023 補的更完整了。

然後有 Graph 相關的標準也被定義進 SQL:2023，原文介紹的也不是很多，看起來是要跨足過來？

calloc() 與 malloc() 的差異

前陣子在 Hacker News Daily 上看到的，原文是 2016 的文章：「Why does calloc exist?」，裡面講的東西包括了 implementation dependent 的項目，所以要注意一下他的結論未必適用於所有的平台與情境。

malloc() 與 calloc() 的用法是這樣，其中 calloc() 會申請 count 個 size 的空間：

void* buffer1 = malloc(size);
void* buffer2 = calloc(count, size);

第一個差異是，count * size 可能會 overflow (而 integer overflow 在 C 裡面是 undefined behavior)，這點除非你在乘法時有檢查，不然大多數的行為都還是會生一個值出來。

而 calloc() 則是會幫你檢查，如果會發生 overflow 的時候就不會真的去要一塊記憶體用。

第二個差異是 calloc() 保證會將內容都設定為 0，這點在 POSIX 的標準裡面是這樣寫的：

The calloc() function shall allocate unused space for an array of nelem elements each of whose size in bytes is elsize. The space shall be initialized to all bits 0.

但作者就發現 malloc() + memset() + free() 還是比 calloc() + free() 慢很多：

~$ gcc calloc-1GiB-demo.c -o calloc-1GiB-demo
~$ ./calloc-1GiB-demo
calloc+free 1 GiB: 3.44 ms
malloc+memset+free 1 GiB: 365.00 ms

研究發現是 calloc() 用了 copy-on-write 的技巧，先把所有的 page 都指到同一塊完全被塞 0 的記憶體，只有在真的寫到該段記憶體時，系統才會要一塊空間來用：

Instead, it fakes it, using virtual memory: it takes a single 4 KiB page of memory that is already full of zeros (which it keeps around for just this purpose), and maps 1 GiB / 4 KiB = 262144 copy-on-write copies of it into our process's address space. So the first time we actually write to each of those 262144 pages, then at that point the kernel has to go and find a real page of RAM, write zeros to it, and then quickly swap it in place of the "virtual" page that was there before. But this happens lazily, on a page-by-page basis.

但畢竟這是 implementation dependent，看看有個印象就好。

C 語言裡面的 ??! 符號

在 Hacker News Daily 上看到這個奇怪的知識：「What does the ??!??! operator do in C? (stackoverflow.com)」，原文在 Stack Overflow 上：「What does the ??!??! operator do in C?」。

這是 trigraph，在 C89 就有了，從 Rationale for International Standard—Programming Languages—C 這邊的 5.2.1.1 可以看到 trigraph 的歷史原因：

Trigraph sequences were introduced in C89 as alternate spellings of some characters to allow the implementation of C in character sets which do not provide a sufficient number of non-alphabetic graphics

而且是強制要求實做：

Implementations are required to support these alternate spellings, even if the character set in use is ASCII, in order to allow transportation of code from systems which must use the trigraphs. AMD1 also added digraphs (see §6.4.6 and §MSE.4).

其中遇到的問題就是當年得決定 C 可以用的 charset，得考慮到很多不同機器 charset 相容性的問題：

The C89 Committee faced a serious problem in trying to define a character set for C. Not all of the character sets in general use have the right number of characters, nor do they support the graphical symbols that C users expect to see. For instance, many character sets for languages other than English resemble ASCII except that codes used for graphic characters in ASCII are instead used for alphabetic characters or diacritical marks. C relies upon a richer set of graphic characters than most other programming languages, so the representation of programs in character sets other than ASCII is a greater problem than for most other programming languages.

然後就使用了 ISO/IEC 646 這個標準 (要記得 Unicode 1.0.0 是 1991 年才出現)：

The solution is an internationally agreed-upon repertoire in terms of which an international representation of C can be defined. ISO has defined such a standard, ISO/IEC 646, which describes an invariant subset of ASCII.

The characters in the ASCII repertoire used by C and absent from the ISO/IEC 646 invariant repertoire are:

[ ] { } \ | ~ ^

後面就是定義 ?? 當作 escape digraph。

算是一個歷史產物，現在不太需要用到了...

TCP 標準被整理到 RFC 9293

看到「RFC 9293: Transmission Control Protocol (TCP)」這篇，主要是把本來分散在各個 RFC 的文件 (從 RFC 793 開始) 全部整理成一份，另外把一些已知的勘誤表放進來：

This document specifies the Transmission Control Protocol (TCP). TCP is an important transport-layer protocol in the Internet protocol stack, and it has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793. This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093, 6429, 6528, and 6691 that updated parts of RFC 793. It updates RFCs 1011 and 1122, and it should be considered as a replacement for the portions of those documents dealing with TCP requirements. It also updates RFC 5961 by adding a small clarification in reset handling while in the SYN-RECEIVED state. The TCP header control bits from RFC 793 have also been updated based on RFC 3168.

然後淘汰掉 (obselete) 一卡車 RFC 文件 XD

翻資料發現 2014 的時候 HTTP/1.1 被幹過一次類似的事情，不過是反過來被拆開：「HTTP/1.1 的更新」，這次把 RFC 2616 幹掉分成 RFC 7230～RFC 7235。

然後今年因為 HTTP 的關係又被幹了一次，這次 HTTP/1.1 又被整回來變成一份文件，但是把裡面的一些概念拆開：「HTTP 標準的翻新」。

其中 RFC 9110 定義 HTTP Semantics，RFC 9111 定義 HTTP Caching，然後 RFC 9112 與 RFC 9113 拿來定義了 HTTP/1.1 與 HTTP/2，另外先把 HTTP/3 的號碼保留下來的 RFC 9114。

不斷 refactor 以及加新功能的文件...

Mozilla 把對各種規格的態度整理成一個網頁

查資料的時候看到「Mozilla Specification Positions」這個，可以看到 Mozilla 對各種規格的態度，分成幾個不同的類型。

有「under consideration」、「important」、「worth prototyping」這幾個從名字上就大概猜的出來意思，接下來的幾個比較有趣的是「non-harmful」、「defer」與「harmful」。

官方的說明是：

  • under consideration: Mozilla's position on this specification is being discussed.
  • important: This specification is conceptually good and is important to Mozilla.
  • worth prototyping: Mozilla sees this specification as conceptually good, and worth prototyping, getting feedback on its value, and iterating.
  • non-harmful: Mozilla does not see this specification as harmful, but is not convinced that it is a good approach or worth working on.
  • defer: Mozilla does not intend to look at this specification at all in the near future.
  • harmful: Mozilla considers this specification to be harmful in its current state.

所以之後看到一些標準時可以過來這邊看看 Mozilla 的態度...

可以在 Cat5 上面跑 1km 的 Ethernet 標準 10BASE-T1L

在 Hacker News 上看到「SPEBlox-Long (10BASE-T1L) - 10Mbps, 1km range」這個產品，看到 10BASE-T1L 這個標準還有蠻有趣的，對應的討論在「10mbps over 1km on a single pair of wires (botblox.io)」這邊。

在維基百科的「Ethernet over twisted pair」這個頁面上面有提到 10BASE-T1S 與 10BASE-T1L 這兩個在 2019 推出的新標準：

Two new variants of 10 megabit per second Ethernet over a single twisted pair, known as 10BASE-T1S and 10BASE-T1L, were standardized in IEEE Std 802.3cg-2019. 10BASE-T1S has its origins in the automotive industry and may be useful in other short-distance applications where substantial electrical noise is present. 10BASE-T1L is a long-distance Ethernet, supporting connections up to 1 km in length. Both of these standards are finding applications implementing the Internet of things.

從標準的名字就可以知道是 10Mbps 的速度，但只用一對線路就可以跑 1km 還蠻有趣的，主打在 IoT 場景...

HTTP 標準的翻新

HTTP 的標準之前都是用新的 RFC 補充與修正舊的標準，所以整體讀起來會比較累，對於開始了解 HTTP 的人會需要交叉讀才能理解。

而這次 RFC 9110～9114 算是一次性的把文件全部重新整理出來，可以看到蠻多人 (以及團體) 都有丟出來對應的看法，這邊丟這兩篇：「A New Definition of HTTP」與「HTTP RFCs have evolved: A Cloudflare view of HTTP usage trends」。

而這五個 RFC，從名稱列出來就可以看出來命名簡單粗暴，把核心概念先拆出來講，然後再講不同 protocol 的部份：

而 Cloudflare 這邊提供了一些資料，可以看到三個 protocol 使用率都算高，而目前最高的是 HTTP/2：

另外比較特別的是 Safari 在 HTTP/3 的趨勢居然有倒縮的情況：

然後 bot 的部份幾乎大家都支援 HTTP/2 了，目前還沒看到太多 HTTP/3 的蹤跡，倒是 LinkedIn 的 bot 有個奇怪的 adoption 然後全部 rollback 的情況，而最近又開始少量導入了：

這次看起來淘汰了 (obsolete) 很多之前的文件，以後要引用得往這五份來引...