Winamp 打算要放出程式碼

在「Winamp has announced that it is "opening up" its source code (」這邊看到的消息,原公告則是在「Winamp has announced that it is opening up its source code to enable collaborative development of its legendary player for Windows.」這邊。

這篇公告上面的「Dec 16, 1」不知道是什麼... Anyway,預定今年九月的時候公開程式碼,在 id=40383890 這邊有提到可能的原因:

Winamp's owners have been going through financial difficulties since last year and as a result have laid off the skeleton crew they previously had maintaining Winamp (their main focus seems to be a streaming service also called Winamp for HTML5 and phones). This looks like they're willing to let the community take over maintenance for PC Winamp, which beats letting it die IMO.


Nvidia 在 Linux 上安裝核心驅動程式時將建議使用開源版本

在「NVIDIA to install open Linux kernel modules by default」這邊看到的新聞,引用的連結是官方的討論區「Unix graphics feature deprecation schedule」這篇。

從 560 開始會議建議使用開源版本:

Starting in the release 560 series, it will be recommended to use the open flavor of NVIDIA Linux Kernel Modules 204 wherever possible (Turing or later GPUs, or Ada or later when using GPU virtualization).

點進去看「Open Linux Kernel Modules」這頁可以看到開源版本有一些專屬功能 (在「The following features will only work with the open kernel modules flavor of the driver」這段),蛋也有一些功能是開源版本沒有的 (在「The following features are not yet supported by the open kernel modules」這段)。

另外 Known Issues 這邊有提到些效能與功耗上的差異。

看起來是 porting 的差不多了?我覺得可以再等一兩個版本 XD

XZ 的後門事件,以及 OpenJS Foundations 也遇到類似的問題

XZ 的後門事件從暴發出來也已經一個多月了,大多數的證據也都分析的差不多了,是差不多可以回顧一下... 然後發現維基百科上面也已經有條目了:「XZ Utils backdoor」,中文版也有:「XZ实用程序后门」。

這次是 open source community 遇到社交工程 (social engineering) 的攻擊,攻擊者順利透過社交手法取得 maintainer & developer 的身份,接下來是慢慢埋 backdoor 的過程。

目前看起來後門是判斷特定的 SSH key 就放行,所以屬於 RCE 類的漏洞,CVSS 給了 10.0 的最高威脅分數。

另外隔壁棚 OpenJS Foundations 也遇到類似的問題:「Open Source Security (OpenSSF) and OpenJS Foundations Issue Alert for Social Engineering Takeovers of Open Source Projects」,在「Failed Credible Takeover Attempt」這段有提到因為 OpenJS Foundations 是因為 security working group 擋下這次的 social engineering。

這是 xz 因為是 backdoor,所以在 performance profiling 時異常而被抓出來,如果是 exploitable 的話就難抓了... 這次的 social engineering 之後有看到一些不同的討論,有些是技術上把 security auditing 拆出來一起做,另外一種是要確保參與的 maintainer & developer 的真實身份。


OpenTofu 釋出第一個 GA 版本 1.7.0

從去年八九月從 Terraform fork 出來並且改名後 (「OpenTF 宣佈從 Terraform 最後一個 Open Source 版本 fork 出來」、「OpenTF (Terraform 的 fork) 改名為 OpenTofu」),總算是推出第一個 GA 版本了:「OpenTofu 1.7.0 is out with State Encryption, Dynamic Provider-Defined Functions, and more」。

除了把 trademark 相關的東西換掉以外,還實作了一些功能,這樣化半年弄出個起頭,接下來看後續的能量?好像還行...

MS-DOS v4.0 的程式碼以 MIT license 釋出

Hacker News 上的消息「Open Sourcing DOS 4 (」,原文在「Open Sourcing DOS 4」。

Hacker News 裡面的討論有拉出一些有趣的 source code 註解,不過我比較好奇為什麼是挑 v4.0 而不是其他版本,看說明應該是剛好遇到對的人與對的團體?

A young English researcher named Connor "Starfrost" Hyde recently corresponded with former Microsoft Chief Technical Officer Ray Ozzie about some of the software in his collection. Amongst the floppies, Ray found unreleased beta binaries of DOS 4.0 that he was sent while he was at Lotus. Starfrost reached out to the Microsoft Open Source Programs Office (OSPO) to explore releasing DOS 4 source, as he is working on documenting the relationship between DOS 4, MT-DOS, and what would eventually become OS/2. Some later versions of these Multitasking DOS binaries can be found around the internet, but these new Ozzie beta binaries appear to be much earlier, unreleased, and also include the source.

這些程式碼主要都是考古分析用了,不知道什麼時候 MS-DOS 6.22 的 code 會冒出來...

IBM 買 HashiCorp

居然是 IBMHashiCorp 啊:「IBM to buy HashiCorp in $6.4 billion deal to expand cloud software」。

Red Hat 先前在 RHEL 上面的事情讓 open source community 頗感冒,加上 HashiCorp 先前切到 BSL (先前有提到的:「HashiCorp 將放棄 Open Source License,改採用 BSL 1.1」),看起來差不多有個概念了?

另外 IBM 這邊官方新聞稿在這:「IBM to Acquire HashiCorp, Inc. Creating a Comprehensive End-to-End Hybrid Cloud Platform」。

Redis 的眾多 fork

從「Redis 改變授權,變成非開源軟體」差不多過去一個禮拜了,瞬間冒出一卡車 Redis fork:「The race to replace Redis」。

文章裡提到的第一個是 Valkey,在 Redis 宣佈改變授權後幾天 fork 出來的。

第二個則是 KeyDB,是很久前就 fork 出來實作 multi-threading 的公司,後來公司被 Snap 買走後 open source,但因為 fork 的很早,後續 Redis 增加的功能就沒有跟上了...

第三個則是 Redict,這是 SourceHut 這邊的 fork 版本。

第四個不算是 fork,是微軟前幾天公開的 Garnet,用 C# 寫的,也因為不是 fork,相容性當然比不上前面幾個。

另外一個文章帶出來的重要資訊,是目前 Redis 的 contributor 分佈,可以看到其實 Redis 本家不算多,這樣 Redis 決定硬幹 BSL + SSPL 的決定就頗值得玩味了:

可以看看 Redis 接下來會不會有什麼重量級的功能要推出?

Redis 改變授權,變成非開源軟體

Redis 宣佈拿掉開源授權:「Redis Adopts Dual Source-Available Licensing」,對應的 git commit 在「Change license from BSD-3 to dual RSALv2+SSPLv1 (#13157)」這邊可以看到。

Starting with Redis 7.4, Redis will be dual-licensed under the Redis Source Available License (RSALv2) and Server Side Public License (SSPLv1).

算是今天蠻熱的新聞之一,不過算是在預期之內的變化,因為 Redis 在 2018 年就把很多他們自己開發的 proprietary component 變成 SSPL,現在主體也變其實不算太意外,後續就是看社群的 fork 凝聚的力量會比較大,還是 Redis 公司方的力量比較大... 尤其在 Redis 已經實作了許多 data structure 後,Redis 公司想要套現這件事情是否還有機會?

不過比較特別的反倒是微軟... 微軟早了一兩天發佈了 Redis 相容的實作 Garnet

Garnet is a remote cache-store from Microsoft Research that offers strong performance (throughput and latency), scalability, storage, recovery, cluster sharding, key migration, and replication features. Garnet can work with existing Redis clients.



先前提過「在 Intel 內顯上面直接跑 CUDA 程式的 ZLUDA」,結果後來事情大翻轉,AMD 跑去贊助專案,變成支援 AMD GPU 了:「AMD Quietly Funded A Drop-In CUDA Implementation Built On ROCm: It's Now Open-Source」,專案在 GitHubvosen/ZLUDA 這邊,而這包支援 AMD GPU 的 commit log 則是在 1b9ba2b2333746c5e2b05a2bf24fa6ec3828dcdf 這包巨大的 commit:

Nobody expects the Red Team

Too many changes to list, but broadly:
* Remove Intel GPU support from the compiler
* Add AMD GPU support to the compiler
* Remove Intel GPU host code
* Add AMD GPU host code
* More device instructions. From 40 to 68
* More host functions. From 48 to 184
* Add proof of concept implementation of OptiX framework
* Add minimal support of cuDNN, cuBLAS, cuSPARSE, cuFFT, NCCL, NVML
* Improve ZLUDA launcher for Windows

其中的轉折以及後續的故事其實還蠻不知道怎麼說的... 作者一開始在 Intel 上班,弄一弄 Intel 覺得這沒前景,然後 AMD 接觸後贊助這個專案,到後面也覺得沒前景,於是依照後來跟 AMD 的合約,如果 AMD 覺得沒前景,可以 open source 出來:

Why is this project suddenly back after 3 years? What happened to Intel GPU support?

In 2021 I was contacted by Intel about the development od ZLUDA. I was an Intel employee at the time. While we were building a case for ZLUDA internally, I was asked for a far-reaching discretion: not to advertise the fact that Intel was evaluating ZLUDA and definitely not to make any commits to the public ZLUDA repo. After some deliberation, Intel decided that there is no business case for running CUDA applications on Intel GPUs.

Shortly thereafter I got in contact with AMD and in early 2022 I have left Intel and signed a ZLUDA development contract with AMD. Once again I was asked for a far-reaching discretion: not to advertise the fact that AMD is evaluating ZLUDA and definitely not to make any commits to the public ZLUDA repo. After two years of development and some deliberation, AMD decided that there is no business case for running CUDA applications on AMD GPUs.

One of the terms of my contract with AMD was that if AMD did not find it fit for further development, I could release it. Which brings us to today.

這個其實還蠻好理解的,CUDA 畢竟是 Nvidia 家的 ecosystem,除非你反超越後自己定義一堆自家專屬的功能 (像是當年 MicrosoftIE 上的玩法),不然只是幫人抬轎。

Phoronix 在 open source 前幾天先拿到軟體進行測試,而他這幾天測試的結果給了「頗不賴」的評價:

Andrzej Janik reached out and provided access to the new ZLUDA implementation for AMD ROCm to allow me to test it out and benchmark it in advance of today's planned public announcement. I've been testing it out for a few days and it's been a positive experience: CUDA-enabled software indeed running atop ROCm and without any changes. Even proprietary renderers and the like working with this "CUDA on Radeon" implementation.

另外為了避免測試時有些測試軟體會回傳到伺服器造成資訊外洩,ZLUDA 在這邊故意設定為 Graphics Device,而在這次 open source 公開後會改回正式的名稱:

In my screenshots and for the past two years of development the exposed device name for Radeon GPUs via CUDA has just been "Graphics Device" rather than the actual AMD Radeon graphics adapter with ROCm. The reason for this has been due to CUDA benchmarks auto-reporting results and other software that may have automated telemetry, to avoid leaking the fact of Radeon GPU use under CUDA, it's been set to the generic "Graphics Device" string. I'm told as part of today's open-sourcing of this ZLUDA on Radeon code that the change will be in place to expose the actual Radeon graphics card string rather than the generic "Graphics Device" concealer.

作者的測試看起來在不同的測試項目下差異頗大,但如果依照作者的計算方式,整體效能跟 OpenCL 版本差不多:

Phoronix 那邊則是做了與 Nvidia 比較的測試... 這邊拿的是同樣都有支援 Nvidia 與 AMD 家的卡的 Blender 測試,然後跑出來的結果讓人傻眼,透過 ZLUDA 轉譯出來的速度比原生支援的速度還快,這 optimization 看起來又有得討論了:(這是 BMW27 的測試,在 Classroom 的測試也發現一樣的情況)

但即使如此,CUDA over AMD GPU 應該還是不會起來,官方會儘量讓各 framework 原生支援,而大多數的開發者都是在 framework 上面開發,很少會自己從頭幹...

Gentoo 宣佈支援 binary package

Hacker News 上看到「Gentoo goes Binary (」這篇,原文在「Gentoo goes Binary!」這。

Gentooportage 知名,這點在維基百科條目開頭就有提出來:

Gentoo Linux (pronounced /ˈdʒɛntuː/ JEN-too[3]) is a Linux distribution built using the Portage package management system. Unlike a binary software distribution, the source code is compiled locally according to the user's preferences and is often optimized for the specific type of computer.

這算是 Gentoo 的特色,不過即使 Gentoo 超愛 source package,也還是支援 binary package 安裝,但以前只提供重點套件,這包括了像是 Linux kernel 以及 gcc 這種套件,總是要有這些東西才能開始編軟體。

而這次公告宣佈要全面支援 binary package 算是個大轉變:

To speed up working with slow hardware and for overall convenience, we’re now also offering binary packages for download and direct installation!

目前 binary package 的主力會在 amd64 與 arm64 平台,然後提到這會對 mirror site 有額外的空間需求:

For most architectures, this is limited to the core system and weekly updates - not so for amd64 and arm64 however. There we’ve got a stunning >20 GByte of packages on our mirrors, from LibreOffice to KDE Plasma and from Gnome to Docker. Gentoo stable, updated daily.

從文末的圖也可以看到「the amount of binary package data in GByte for each architecture」得資訊:

想得到的客群大概是兩種,第一類是對於想用 Gentoo 看看的人來說會更好入手,尤其是手上是 Raspberry Pi 這些 CPU 不快的 SBC 會方便不少...

另外一種是不太在意效能,但是對某些 package 來說有高度客製化需求的人,會希望自己編這些 package 的人,透過 portage 自己調整。