Today’s theme continued the lightning talk format. It had been two months since the previous meetup.
At Kaohsiung Student Union, we continued borrowing a free venue in the name of a student club (totally real).
Notes are on HackMD.
First, Shawn shared the development prospects of RedHat OpenShift, explaining the upstream and downstream development relationship between OKD and OCD. He clarified the relationship among Fedora, CentOS Stream, and RHEL, which made me understand that CentOS Stream is not actually that unstable. He thinks its positioning is close to Ubuntu LTS. CentOS Stream still has major version numbers and locks the kernel version. RedHat still sends fixes to CentOS Stream, and then the open source community helps test for bugs. Shawn believes this can form a healthier ecosystem. But I feel that if that is the case… then I might as well just use Ubuntu LTS.
He also introduced the benefits of Fedora CoreOS, which heavily adopts bootc and deploys systems in an image-based way. He mentioned that when the time is ripe, rpm-ostree may be replaced by composefs in the future, which can effectively use the Linux kernel’s erofs mechanism to handle system files. But what I want to ask is: now that there are already products implemented with bootc such as uBlue Bazzite, their biggest problem is that it is hard for users to manually install .rpm files locally; they can only rebuild the system image, called local layering. So how will composefs solve this problem? The two of us did not discuss our way to a satisfactory answer, and this technology is not finalized yet either. We can only wait and see in the future. Honestly, I do not want to manually build an image in the cloud and pull it down for deployment every time I want to install some extra package on the system.
Then I, with my shallow knowledge and limited learning, went on stage to demonstrate Phosh, introducing the development process of the Linux phone ecosystem and the possibility of replacing Android. For the slides, I used the Phosh desktop introduction I made a few months ago. Although everyone present was quite interested in the Poco F1 (postmarketOS) and Pinetab 2 (Arch Linux ARM) I brought, as someone who was tortured by these devices for a long time and finally resigned myself to using an iPad, I had all kinds of mixed feelings… Phones and tablets that can run Linux are indeed very interesting toys, but they are only toys.
Hsu Chia-Chun from the Software Liberty Association Taiwan (SLAT) demonstrated the AI features of Nextcloud Office. They had already launched Copilot-like assistance features similar to Microsoft Office at the end of 2023, mainly implemented by connecting to external language model APIs such as ChatGPT. However, he mentioned that this cannot be processed asynchronously, and even running a simple text translation takes a long wait… It seems there are still many rough edges. This kind of web-based AI solution should really learn from Google Docs. It is truly a blessing for lazy people.
In addition, he mentioned that Taiwan’s Ministry of Digital Affairs and his company developed the “MODA ODF Document Application Tool”, which is a localized LibreOffice designed for Taiwanese users. Many government agencies have gradually adopted it. Now it has also launched a web version, which can be downloaded and deployed from the official website. I asked him on the spot: what kind of genius idea did their company have to split LibreOffice into 10 .deb files for distribution!? Am I supposed to install them all at once with apt install ./*.deb? Even the LibreOffice official website does not do that. The main thing is that this packaging method is ugly… I hope they can learn from WPS Office and provide a Flatpak version or Docker image, which would be easier for personal users to deploy.
Also, I noticed when using SLAT’s Nextcloud Office a few years ago: why deliberately dye LibreOffice’s colors to look the same as Word? Today I finally got the expected answer: it makes it easier for civil servants to adapt. Sigh.
Finally, Rick demonstrated new Rust features, using zscript to let shell script-like programs be compiled and executed by cargo. Hey, that is much more convenient. He also called on everyone to install ZeroClaw. This is a greatly debloated OpenClaw, and Skills can be written with wasm.
After the meetup, I met Hsu Chung-Yu and Hsu Chia-Chun. It turns out they are also SLAT members. How magical. I thought I would never in my life run into people around me who had joined this kind of cult organization.
Five days later, Hsu Chung-Yu hoped I could help him solve the problem of Line being unable to install.
So my first offline InstallFest turned out to be helping someone solve how to install Line on Linux. The problem was: why could I successfully install the desktop Line exe with Bottles in my Arch Linux & Debian environments, while on his Linux computer all kinds of miraculous errors popped up?
So I came out to investigate.
Today I met this god-tier Debian user at Starbucks. Although he uses the Debian Stable branch, he compiles the kernel himself to use the latest kernel. He is already on Kernel 7.0. It turns out he has had this habit for 20 years. Does that not completely defeat the purpose of Debian!? But watching him use KDE, it still seemed quite stable, and he could use the laptop to handle school administrative work. Could it be that the kernel is not that easy to crash? Is it enough as long as Userspace is stable? No, that is not right… new kernels can easily cause unstable suspend, you know.
Then, after actually testing it, I found that his Debian computer really did throw all kinds of miraculous errors. For example, Wine would show the error “Application could not be started, or no application associated with the specified file. ShellExecuteEx failed: Internal error.” when running any file.
It was not the Kernel, not Wayland, so what exactly caused it… The Flatpak environment should not be affected by the host machine…
After trying for two hours, I gave up. I had no choice but to ask him to reinstall. This Debian environment of his had been used for a long time, and I do not know which program touched the settings.
Later, the results of his own testing in a virtual machine confirmed that a freshly installed Debian KDE could install Line, showing that the problem was indeed with his computer environment.
