Tag: gnu

GNU Screen 5.0.0

在 Hacker News 上看到 GNU Screen 5.0.0 的消息：「GNU Screen 5.0 Released (savannah.gnu.org)」，官方網站是「GNU Screen v.5.0.0 is released」這邊。

從 source code 的下載頁面 https://ftp.gnu.org/gnu/screen/ 這邊可以看到上次 major version 的跳動 (從 3.9.15 跳到 4.0.0) 是 2004 年了，不過這次跳 5.0.0 不知道是什麼原因，從列出來的功能裡面是有看到不少 removed 的項目。

另外下載頁面上面最早只有 1995 年的檔案，這邊好像沒有所有的版本資訊；翻一下維基百科的 GNU Screen 條目，是個 1987 年誕生的軟體，比 CVS 還早 (1990 年出)，當初的慣例都是一堆 patch 檔案傳來傳去 (比較小)。

當年剛接觸 FreeBSD 環境時開始學各種工具時學會的工具，記得當年還是各種 locale 百家齊放的時候還得自己 patch & compile 搞 Big5 與 UTF-8 的轉換，

不過後來都跳到 tmux 了，雖然當年的 .screenrc 還留在 dotfiles 包裡面。

Linux 上的 GNU sed 與 macOS 內的 sed 的 in-place 差異

結論：用 Perl。

寫 shell script 的時候遇到的問題，在 Linux 上面使用 sed 換檔案裡面的字串，但不想要產生 backup file 的方式是：

sed -i -e 's/foo/bar/' example.txt

但在 macOS 內建的 sed 則是：

sed -i '' -e 's/foo/bar/' example.txt

也就是說前者 GNU sed 是處理 $1 (argv[1]，anyway) 後面貼著的參數，而後者 macOS 的則是吃 $2 (argv[2]) 的參數。

在 Stack Overflow 上的「sed in-place flag that works both on Mac (BSD) and Linux」這邊有討論，看起來 sed 上沒有通解。

翻了 The Open Group 上的說明，sed 應該是定義在 POSIX 裡面，而從文件裡面沒有提到 backup file 可以知道這是各家自己實作的功能：「sed」。

所以一種解法是用 detection 的方式針對不同的 sed 給不同的指令；而另外一種解法是找其他工具。後者考慮到普及性，用 Perl 應該會是比較好的方式，目前不是 minimal 類的系統應該都還有 Perl 可以用：

perl -pi -e 's/foo/bar/' example.txt

但這樣跑在 CI 裡面的時候就得小心一點了，如果選到 minimal image 的話就會中獎... (煩躁？)

GNU Make 在 4.4 引入的 --shuffle

Hacker News 首頁上看到的，作者送了一個提案到 GNU Make，後來被採用，在 4.4 版引入了 --shuffle 指令：「New make --shuffle mode」。

這個功能主要是想要找出在 Makefile 裡面沒有被定義好，平常是因為 side effect 而沒有出錯的地方。

像是作者就發現 libgfortran 沒有把 libquadmath 放到 dependency 的問題：

For example gcc’s libgfortran is missing a libquadmath build dependency. It is natural not to encounter it in real world as libquadmath is usually built along with other small runtimes way before g++ or gfortran is ready.

他的基本想法是把 target 的順序打亂掉，也就是在有指定 --shuffle 時，不一定會照 a -> b -> c 的順序往下遞迴，而可能會是 c -> b -> a 或是其他的順序：

all: a b c

這樣對於抓那些在 -j 平行編譯時會出包的套件也很有幫助，不需要在 -j 開很大的情況下才能重製問題，而是平常就有機會在 CI 環境下被抓出來。

檔案壓縮順序造成壓縮率的差異

Hacker News Daily 上看到「Why are tar.xz files 15x smaller when using Python's tar library compared to macOS tar?」這篇，作者問了為什麼他用 Python 的 tarfile 壓出來比起用 tar 壓出來小了 15 倍，檔案都是 JSON 檔壓成 XZ 格式：

I'm compressing ~1.3 GB folders each filled with 1440 JSON files and find that there's a 15-fold difference between using the tar command on macOS or Raspbian 10 (Buster) and using Python's built-in tarfile library.

看到 1440 個檔案應該會有直覺是一分鐘一個檔案，跑一天的量...

隔天他把原因找出來了，在裝了 GNU Tar 並且加上 --sort='name' 參數後，壓出來的大小就跟 Python 的 tarfile 差不多了：

Ok, I think I found the issue: BSD tar and GNU tar without any sort options put the files in the archive in an undefined order.

After installing GNU tar on my Mac with:

brew install gnu-tar

And then tarring the same folder, but with the --sort option:

gtar --sort='name' -cJf zsh-archive-sorted.tar.xz /Users/user/Desktop/temp/tar/2021-03-11

I get a .tar.xz archive of 1.5 MB, equal to the archive created by the Python library.

底層的原因是檔名與檔案內容有正相關的相似度 (因為裡面都是 sensor 資料)，依照檔名排序壓縮就等於把類似的 JSON 檔案放在一起壓，使得 xz 可以利用這點急遽拉高壓縮率：

My JSON files contain measurements from hundreds of sensors. Every minute I read out all sensors, but only a few of these sensors have a different value from minute to minute.

By sorting the files by name (which has the creation unixtime at the beginning of it), two subsequent files have very little different characters between them. Apparently this is very favourable for the compression efficiency.

遇到類似的情境可以當作 tuning 的一種，測試看看會不會變小很多...

Vim 的 virtualedit 與 GNU Make 內的 .PHONY

在「Writing a Book with Pandoc, Make, and Vim」這邊看到作者在講他怎麼用 Pandoc + GNU Make + Vim 寫書，不過我這邊看到兩個有趣的東西 (標題提到的那兩個)，拉出來寫一下...

一個是 Vim 的 set virtualedit=all，可以不受限制的移動，等到實際編輯時再產生出對應需要的空白，這對於畫表格會方便不少：

另外一個是 GNU Make 的用法，平常我們都是在 .PHONY 裡指定實際上不會存在的 target：

.PHONY: clean
clean:
        rm -rf ./output

這邊作者提供的方式是產生一個叫做 phony 的 target，然後就不需要在 .PHONY 裡條列，而是各自在自己的 target 裡面引用 phony：

.PHONY: phony
clean: phony
        rm -rf ./output

不過作者有提到效能問題：

Note that this trick can slow down huge Makefiles.

另外作者又提醒我 draw.io 這個好用的工具，之前用過幾次後就忘記了...

勸人從 Linux 跳到 FreeBSD 的戰文...

前幾天在 Facebook 上看到正妹朋友的貼文，然後在 Hacker News Daily 上也看到了：「Technical reasons to choose FreeBSD over GNU/Linux」。

標準的戰文 XDDD

在這篇講的是 FreeBSD 在技術上的優勢 (雖然我覺得很多不是優勢...)，作者在一月的時候有另外兩篇在講 BSD (不只是 FreeBSD) 與 Linux，主題偏政治面 (包括了社群的運作方式) 與 license 之類的問題，也是戰文：「Why you should migrate everything from Linux to BSD」與「Why you should migrate everything from Linux to BSD - part 2」。

不過畢竟就是戰文，拿爆米花來吃就好，還是用的順手比較重要。當初 FreeBSD 的 issue tracking system 換掉以後，覺得太卡就抽手了，不然還蠻愛 Ports 的架構的...

Square 在使用條款裡禁止 AGPLv3+ 的軟體

雖然 AGPL 系列的確不是什麼好貨色，也的確有不少人批評過，但 Square 直接透過自家的平台服務攻擊 AGPLv3+ 就很稀奇了？

在「Square’s terms of service forbid use of AGPL-licensed software in online stores (squareup.com)」這邊看到的，公告的條款 (尚未生效) 是「Additional Point of Sale Terms of Service」這個站台，出自於這段：

B. Content Restrictions. In addition to the restrictions set forth in these Additional Product Terms, the General Terms and Payment Terms, you will not:

[...]

15. use, under any circumstance, any open source software subject to the GNU Affero General Public License v.3, or greater;

是直接指名而不是誤殺，不知道是發生什麼事情...

現在 Hacker News 上有些人猜測是律師團認為 AGPL 會反過來影響 Square 自己的程式碼也被感染？反正現在變成 PR 事件了，加上資訊也不足，先蹲著看...

GitHub 上的軟體授權分佈

雖然 GitHub 有提供 license 相關的 API 可以查，但因為準確度不高 (只要稍微改到，GitHub 就無法偵測到正確的 license)，所以有人決定用 machine learning 的方式另外分析：「Detecting licenses in code with Go and ML」。當然這邊是分析公開的部份：

最大包的是 MIT License，次之是 Apache-2.0 (問號那群先不管)，再來是 GPL 家族的各版本。沒有太特別的意外發生...

兩個 gperf...

翻資料的時候覺得怎麼跟印象中的不太一樣，多花些時間翻了一下，發現原來有兩個東西同名...

一個是 GNU 的 gperf，給定字串集合，產生 C 或 C++ 的 perfect hash function (i.e. no collision)：

GNU gperf is a perfect hash function generator. For a given list of strings, it produces a hash function and hash table, in form of C or C++ code, for looking up a value depending on the input string. The hash function is perfect, which means that the hash table has no collisions, and the hash table lookup needs a single string comparison only.

另外一個是 Google 弄出來的 gperftools，malloc() 的替代品以及效能分析工具：

gperftools is a collection of a high-performance multi-threaded malloc() implementation, plus some pretty nifty performance analysis tools.

瀏覽器裡控制 GDB...

還是在 Twitter 上看到的奇怪玩具，專案在「cs01/gdbgui」，是個可以在瀏覽器裡控制 GDB 的軟體：

Browser-based frontend to gdb (gnu debugger). Add breakpoints, view the stack, visualize data structures, and more in C, C++, Go, Rust, and Fortran. Run gdbgui from the terminal and a new tab will open in your browser.

截圖就看得出來大致的界面：

不過我還是偏好用 terminal 啦，推薦「CppCon 2015: Greg Law " Give me 15 minutes & I'll change your view of GDB"」這個演講，裡面講了不少在 terminal 下使用 GDB 的技巧：