Hírolvasó

I sincerely regret to see Linux kernel patches like this one removing Russian developers from the MAINTAINERS file. To me, it is a sign or maybe even a symbol of how far the Linux kernel developer community I remember from ~ 20 years ago has changed, and how much it has alienated itself from what I remember back in the day.

In my opinion this commit is wrong at so many different levels:

• it is intransparent. Initially it gave no explanation whatsoever (other than some compliance hand-waving). There was some follow-up paraphrasing one paragraph of presumed legal advice that was given presumably by Linux Foundation to Linus. That's not a thorough legal analysis at all. It doesn't even say to whom it was given, and who (the individual developers? Linux Foundation? Distributors?) is presumed to be subject to the unspecified regulations in which specific jurisdiction

• it discriminates developers based on their presumed [Russian] nationality based on their name, e-mail address domain name or employer.

A later post in the thread has clarified that it's about an U.S. embargo list against certain Russian individuals / companies. It is news to me that the MAINTAINERS file was usually containing Companies or that the Linux kernel development is Companies engaging with each other. I was under the naive assumption that it's individual developers who work together, and their employers do not really matter. Contributions are judged by their merit, and not by the author or their employer / affiliation. In the super unlikely case that indeed those individual developers removed from the MAINTAINERS file would be personally listed in the embargo list: Then yes, of course, I agree, they'd have to be removed. But then the commit log should of course point to [the version] of that list and explicitly mention that they were personally listed there.

And no, I am of course not a friend of the Russian government at all. They are committing war crimes, no doubt about it. But since when has the collaboration of individual developers in an open source project been something related to actions completely unrelated to those individuals? Should I as a German developer be excluded due to the track record of Germany having started two world wars killing millions? Should Americans be excluded due to a very extensive track record of violating international law? Should we exclude Palestinians? Israelis? Syrians? Iranians? [In case it's not obvious: Those are rhetorical questions, my position is of course no to all of them].

I just think there's nothing more wrong than discriminating against people just because of their passport, their employer or their place of residence. Maybe it's my German upbringing/socialization, but we've had multiple times in our history where the concept of **Sippenhaft** (kin liability) existed. In those dark ages of history you could be prosecuted for crimes committed by other family members.

Now of course removal from the MAINTAINERS file or any other exclusion from the Linux kernel development process is of course not in any way comparable to prosecution like imprisonment or execution. However, the principle seems the same: An individual is punished for mere association with some others who happen to be committing crimes.

Now if there really was a compelling legal argument for this (I doubt it, but let's assume for a second there is): In that case I'd expect a broad discussion against it; a reluctance to comply with it; a search for a way to circumvent said legal requirement; a petition or political movement against that requirement.

Even if there was absolutely no way around performing such a "removal of names": At the very least I'd expect some civil disobedience by at least then introducing a statement into the file that one would have hoped to still be listing those individuals as co-maintainers but one was forced by [regulation, court order, ...] to remove them.

But the least I would expect is for senior Kernel developers to simply do apply the patch with a one-sentence commit log message and thereby disrespect the work of said [presumed] Russian developers. All that does is to alienate individuals of the developer community. Not just those who are subject to said treatment today, but any others who see this sad example how Linux developers treat each other and feel discouraged from becoming or remaining active in a community with such behaviour.

It literally hurts me personally to see this happening. It's like a kick in the gut. I used to be proud about having had an involvement with the Linux kernel community in a previous life. This doesn't feel like the community I remember being part of.

Currently in Rust, there is no efficient and safe way to turn an array of bytes into a structure that corresponds to the array. Changing that was the topic of Jack Wrenn's talk this year at RustConf: "Safety Goggles for Alchemists". The goal is to be able to "transmute" — Rust's name for this kind of conversion — values into arbitrary user-defined types in a safer way. Wrenn justified the approach that the project has taken to accomplish this, and spoke about the future work required to stabilize it.

Version 14.0 of the privacy-focused Tor browser has been released.

This is our first stable release based on Firefox ESR 128, incorporating a year's worth of changes shipped upstream in Firefox. As part of this process we've also completed our annual ESR transition audit, where we reviewed and addressed over 200 Bugzilla issues for changes in Firefox that may negatively affect the privacy and security of Tor Browser users. Our final reports from this audit are now available in the tor-browser-spec repository on our Gitlab instance.

Jakub Kadlčík announced on his blog that Fedora's Copr build system will be dropping support for building modules (groups of RPM packages that are built, installed, and shipped together) soon:

The Fedora Modularity project never really took off, and building modules in Copr even less so. We've had only 14 builds in the last two years. It's not feasible to maintain the code for so few users. Modularity has also been retired since Fedora 39 and will die with RHEL 9.

Modularity features in Copr are now deprecated, and it will not be possible to submit new module builds after April 2025. LWN covered some of the problems with Fedora's modularity initiative in 2019.

In July, at the GNOME annual general meeting (AGM), held at GUADEC 2024, the message from the GNOME Foundation board was that all was well, financially speaking. Not great, but the foundation was on a break-even budget and expected to go into its next fiscal year with a similar budget and headcount. On October 7, however, the board announced that it had had to make some cuts, including reducing its staff by two people. This is not, however, strictly a GNOME problem: similar organizations, such as the Python Software Foundation (PSF), KDE e.V., and the Free Software Foundation Europe (FSFE) are seeing declines in fundraising while also being affected by inflation.

Security updates have been issued by Debian (dmitry, libheif, and python-sql), Fedora (suricata and wireshark), SUSE (cargo-c, libeverest, protobuf, and qemu), and Ubuntu (golang-1.22, libheif, unbound, and webkit2gtk).

Version 0.104 of Game of Trees has been released (and the port updated).

* got 0.104; 2024-10-22 see git repository history for per-change authorship information - gotd.conf: document the macro syntax - tog: prevent a segfault upon unexpected object type in ref list view - fix pack file creation in the presence of tagged tag objects - plugged some memory leaks - fix a crash when unstaging a file which has been removed from disk - gotwebd: fix out of bounds access while handling the configuration

Perhaps one of the more surprising changes in the 6.12-rc4 development kernel was the removal of several entries from the kernel's MAINTAINERS file. The patch performing the removal was sent (by Greg Kroah-Hartman) only to the patches@lists.linux.dev mailing list; the change was included in a char-misc drivers pull request with no particular mention.

The explanation for the removal is simply "various compliance requirements". Given that the developers involved all appear to be of Russian origin, it is not too hard to imagine what sort of compliance is involved here. There has, however, been no public posting of the policy that required the removal of these entries.

Update: Linus Torvalds has since publicly supported this action and said that it will not be reverted.

Update 2: James Bottomley has clarified the requirements: If your company is on the U.S. OFAC SDN lists, subject to an OFAC sanctions program, or owned/controlled by a company on the list, our ability to collaborate with you will be subject to restrictions, and you cannot be in the MAINTAINERS file.

Some of the readers of this blog know that I have a very special relationship with Taiwan. As a teenager, it was the magical far-away country that built most of the PC components in all my PCs since my first 286-16 I got in 1989. Around 2006-2008 I had the very unexpected opportunity to work in Taiwan for some time (mainly for Openmoko, later some consulting for VIA). During that time I have always felt most welcome in and fascinated by the small island nation who managed to turn themselves into a high-tech development and manufacturing site for ever more complex electronics. And who managed to evolve from decades of military dictatorship and turn into a true democracy - all the while being discriminated by pretty much all of the countries around the world, as everybody wanted to benefit from cheap manufacturing in mainland China and hence expel democratic Taiwan from the united nations in favour of communist mainland Chine.

I have the deepest admiration for Taiwan to manage all of their economic success and progress in terms of democracy and freedom despite the political situation across the Taiwan strait, and despite everything that comes along with it. May they continue to have the chance of continuing their path.

Setting economy, society and politics behind: On a more personal level I've enjoyed their culinary marvels from excellent dumplings around every street corner to niu rou mien (beef noodle soup) to ma la huo guo (spicy hot pot). Plus then the natural beauty, particularly of the rural mountainous regions once you leave the densely populated areas around the coast line and the plains of the north west.

While working in Taiwan in 2006/2007 I decided to buy a motorbike. Using that bike I've first made humble day trips and later (once I was no longer busy with stressful work at Openmoko) multiple week-long road trips around the island, riding on virtually any passable road you can find. My typical routing algorithm is "take the smallest possible road from A to B".

So even after concluding my work in Taiwan, I returned again and again for holidays, each one with more road trips. For some time, Taiwan had literally become my second home. I had my favorite restaurants, shops, as well as some places around the rural parts of the Island I cam back to several times. I even managed to take up some mandarin classes, something I never had the time for while doing [more than] full time work. To my big regret, it's still very humble beginner level; I guess had I not co-started a company (sysmocom) in Berlin in 2011, I'd have spent more time for a more serious story.

In any case, I have nothing but the fondest memory of Taiwan. My frequent visits cam to a forcible halt with the COVID-19 pandemic, Taiwan was in full isolation in 2020/21, and even irrespective of government regulations, I've been very cautious about travel and contact. Plus of course, there's always the bad conscience of frequent intercontinental air travel.

Originally I was planning to finally go on an extended Taiwan holiday in Summer 2024, but then the island was hit by a relatively serious earthquake in April, affecting particularly many of the remote mountain regions that are of main interest to me. There are some roads that I'd have wanted to ride ever since 2008, but which had been closed every successive year when I went there, due to years of reconstructions after [mostly landslides following] earthquakes and typhoons. So I decided to postpone it for another year to 2025.

However, in an unexpected change of faith, the opportunity arose to give the opening Keyonte at the 2024 Open Compliance Summit in Japan, and along with that the opportunity to do a stop-over in Taiwan. It will just be a few days of Taipei this time (no motorbike trips), but I'm very much looking forward to being back in the city I probably know second or third-best on the planet (after Berlin, my home for 23 years, as well as Nuernberg, my place of birth). Let's see what is still the same and what has changed during the past 5 years!

During the preparation of my current brief visit to Taiwan, I've more or less by coincidence stumbled on several transcripts of oral history interviews with pioneers of the Taiwanese Chip and PC industry (click on the individual transcripts in the Related Records section at the bottom). They have been recorded, transcribed and translated in 2011 by the Computer History Museum under funding from the National Science Council, Taiwan, R.O.C..

As some of you know, I've been spending a lot of time in recent years researching (and practically exploring + re-implementing) historical telecommunications with my retronetworking project.

Retrocomputing itself is not my main focus. I usually feel there's more than enough people operating, repairing, documenting at least many older computers, as well as keeping archives of related software and continuing to spread knowledge on how they operated. Nevertheless, it is a very interesting topic - I just decided that with my limited spare time I want to focus on retro-communications which is under-explored and under-represented.

What's equally important than keeping the old technology alive, is keeping the knowledge around its creation alive. How did it happen that certain technologies were created and became successful or not? How where they key people behind it? etc.

Given my personal history with Taiwan during the last 18 years, it's actually surprising I haven't yet given thought on how or where the history of the Taiwanese IT industry is documented or kept alive. So far I didn't know of any computer museums that would focus especially on the Taiwanese developments. It didn't even occur to me to even check if there are any.

During my work in Taiwan I've had the chance to briefly meet a few senior people at FIC (large mainboard maker that made many PC mainboards I personally used) and both at VIA (chipset + CPU maker). But I didn't ever have a chance to talk about the history.

In any case, I now found those transcripts of interviews. And what a trove of interesting first-hand information they are! If you have an interest in computer history, and want to understand how it came about that Taiwan became such a major player in either the PC industry or in the semiconductor design + manufacturing, then I believe those transcripts are a "must read".

Now they've made me interested to learn more. I have little hope of many books being published on that subject, particularly in a Language I can read (i.e. English, not mandarin Chinese). But I shall research that subject. I'd also be interested to hear about any other information, like collections of historical artifacts, archives, libraries, etc. So in the unlikely case anybody reading this has some pointers on information about the history of the Taiwanese Chip and Computer history, please by all means do reach out and share!.

Once I have sufficiently prepared myself in reading whatever I can find in terms of written materials, I might be tempted to try to reach out and see if I can find some first-hand witnesses who'd want to share their stories on a future trip to Taiwan...

The Image-Based Linux Summit has by now established itself as a yearly event. Following on from last year's edition, the third edition was held in Berlin on September 24, the day before All Systems Go! 2024 (ASG). The purpose of this event is to gather stakeholders from various engineering groups and hold friendly but lively discussions around the topic of image-based Linux — that is, Linux distributions based around immutable images, instead of mutable root filesystems.

The AlmaLinux project has introduced a new edition called "Kitten", which will serve as "the direct upstream for AlmaLinux OS and is the primary point for the AlmaLinux community to engage and influence the future of AlmaLinux OS". Not intended for production use, the first release is based on CentOS Stream 10 source, which will eventually be the basis for Red Hat Enterprise Linux (RHEL) 10:

Because we anticipated many changes in 10, we wanted to get a head start on building AlmaLinux OS 10. Earlier this year we started setting up infrastructure and the build pipeline for AlmaLinux OS 10, and started testing using CentOS Stream 10's code. Based on this preparation work, we are excited to share that we have successfully built a preview of AlmaLinux OS 10 that we are calling AlmaLinux OS Kitten 10.

The first Kitten release previews a number of ways that AlmaLinux will diverge from RHEL 10, including re-enabling frame pointers, including Simple Protocol for Independent Computing Environments (SPICE), and adding packages for Firefox and Thunderbird, which have been dropped from CentOS Stream 10 in favor of Flatpak versions. New installation images for Kitten will be built quarterly. See the release notes for download links, installation instructions, and more information.

The 6.11.5, 6.6.58, 6.1.114, 5.15.169, and 5.10.228 stable kernels have all been released; each contains another set of important fixes.

Version 3.4.0 of the OpenSSL SSL/TLS library has been released. It adds a number of new encryption algorithms, support for "directly fetched composite signature algorithms such as RSA-SHA2-256", and more. See the release notes for details.

Security updates have been issued by Debian (ffmpeg, ghostscript, libsepol, openjdk-11, openjdk-17, perl, and python-sql), Oracle (389-ds-base, buildah, containernetworking-plugins, edk2, httpd, java-1.8.0-openjdk, java-11-openjdk, java-17-openjdk, java-21-openjdk, kernel, python-setuptools, skopeo, and webkit2gtk3), Red Hat (buildah), Slackware (openssl), SUSE (apache2, firefox, libopenssl-3-devel, podman, and python310-starlette), and Ubuntu (cups-browsed, firefox, libgsf, and linux-gke).

A hírességek arcképével való visszaélések megelőzésére hivatkozva szeretné a Meta ismét bevezetni arcfelismerő rendszerét platformjain, egyelőre tesztüzemben.

Az új chip lényegében a PC-s processzort ülteti át mobiltelefonokba.

Cégen belüli feladatok automatizálására szánt, AI-alapú virtuális asszisztenseket készíthetnek nemsokára a Microsoft Copilot Studio felhasználói.

A Full csomagajánlatban összecsomagolhatók mobilos és otthoni FWA díjcsomagok.

A karrierút csúcsának tűnhet valamelyik technológiai óriáscégnél dolgozni, mégis sokan döntenek a felmondás mellett.