The holiday season hustle and bustle is through and I am able to concentrate on reorganizing the messes I have made in getting ready for the season. As the fall time projects finished up, the Christmastime projects kicked into full gear between programming my Christmas light display, baking cookies and making Gingerbread houses with the kids. There come a bunch of other miserable cold weather chores that go along with living on a subsistence farm.

Dear Tumbleweed users and hackers,

7 days have passed since my last review – and as many snapshots have been released since then too. And this even includes my error of one day performing the check-in ‘slightly too late’ (i.e. past midnight). That’s the reason that 0119 did not exist. The check-in was too late and it was already January 20th by then. The snapshots released were numbered 0113, 0114, 0115, 0116, 0117, 0118, and 0120.

The relevant changes/updates published during this week included:

• SQLite 3.37.1 & 3.37.2
• linux-glibc-devel 5.16: syncing up with the kernel
• strace 5.16
• Poppler 22.01.0
• Mesa 21.3.4
• Mozilla Firefox 96.0.1
• shadow 4.11.1 (updated from 4.9)
• Linux kernel 5.16.1

The staging projects are still under control, and there is some space left for your submissions. Keep them coming. Just like these things being worked out at the moment:

• KDE Plasma 5.24 (currently beta is staged and being tested)
• Ruby 3.1 to be introduced and become the main ruby interpreter. Ruby 2.7 and Ruby 3.0 will disappear at the same time (waiting for apparmor fix)
• Python 3.6 interpreter will be removed (once all python36-FOO modules are gone)
• Python 3.10 as the distro default interpreter (a bit down the line)
• GCC 12 introduction has started to be as ready as possible for when the upstream release happens.

openSUSE Tumbleweed had a variety of package updates in smaller snapshots throughout this week.

A few things being prepared for Tumbleweed is that the Linux Kernel 5.16.1 was scheduled for check in and pre-integration tests for GNU Compiler Collection 12 have been started; the rolling release anticipates a merge of GCC 12 in mid-Spring.

The latest Tumbleweed snapshot, 20220117, updated Italian translations for libstorage-ng 4.4.75 and added python-rpm-macros for building the package. Haskell support was dropped in the thrift 0.15.0 package, which is a scalable cross-language service framework for Remote Procedure Call and Inter-Process Communication. No changelogs were provided for the plugins package written in Rust called gstreamer-plugins-rs. The remaining packages in the snapshot were all Python Package Index updates. Among the key PyPI packages to point out is the major version update of python-unicodedata2 14.0.0, which dropped support for End of Life Python 2.7 and 3.5 and added support for Python 3.9, 3.10 and PyPy3. A Tumbleweed arm 20220118 snapshot was release updating the same package listed above.

Anti-virus toolkit ClamAV 0.103.5 was updated in snapshot 20220116; the package fixed a Common Vulnerabilities and Exposures that had an invalid pointer read that could cause a crash. The shadow package that converts UNIX password files to the shadow password format updated to version 4.11.1. This package fixed CVE-2013-4235, which affects the race condition when copying and removing directory trees. Object-oriented Universal Plug and Play framework gupnp 1.4.3 now properly propagates canceled actions in deprecated calls and fixed deprecated asynchronous calls. PyPI updates in this snapshot were python-python-lzo 1.14, python-tables 3.7.0, and the major version update of python-hiredis 2.0.0 dropped support for EOL Python versions 2.7, 3.4, and 3.5.

Mozilla Firefox 96.0.1 was updated in the 20220115 snapshot. The web browser made improvements to the parsing of content-length headers. An update of Mesa 21.3.4 was able to fix a bit of the glitches with the Rockchip RK3399 processor as well as the Panfrost G52 Firefox glitches on YouTube playback. Several patches were added in the 6.3.20220101 ncurses update, which improved the configuration check for getttynam. openSUSE’s perl-Bootloader 0.937 package now supports secure boot on PowerPC and autoyast2 4.4.25 was able to properly merge the autoupgrade workflow when using the online medium. Another package to update in the snapshot was firewalld 1.0.3, which fixed some build features, ipsets and inputs.

The 5.16 strace package had many improvements and a couple implementations in the 20220114 snapshot. The package is used to monitor and tamper with interactions between processes and the Linux kernel, which include system calls, signal deliveries, and changes of process states. The updated Strace package implemented a --secontext=mismatch option to find mismatches in SELinux contexts and implemented decoding of futex_waitv syscall introduced in Linux Kernel 5.16. The update of Flatpak 1.12.3 made minor improvements to the search command, to the list command and to the repair command. Flatpak also fixed a CVE that had a malicious repository, which could have sent invalid application metadata in a way that hides some of the app permissions displayed during installation. The snapshot was a CVE killer thanks to busybox 1.35.0, which addressed 17 CVEs. One of those, CVE-2016-6301, was an Network Time Protocol server denial of service flaw. BusyBox also added some new features in find, date and cpio. The free implementation of the Remote Desktop Protocol, freerdp 2.5.0 backported OpenSSL 3.0 support and some Wayland client clipboard issues. Other packages to update in the snapshot were btrfsprogs 5.16, GNOME display manager gdm 41.3, gnome-session 41.3, poppler 22.01.0 and about 15 more packages.

The snapshot to start the week, 20220113, updated only two packages. The update of 389-ds 2.0.11 fixed various User Interface bugs. This enterprise-class package for Open Source LDAP servers fixed many bugs and also fixed the multiple index types not handled in the openldap migration. The second package to update in the snapshot was sqlite3 3.37.1. This C-language library added the .connection command, allowing the CLI to keep multiple database connections open at the same time. The SQL database engine also added the --safe command-line option that disables dot-commands and SQL statements that might cause side-effects that extend beyond the single database file named on the command-line.

Another arm specific Tumbleweed snapshot was released this week; the arm 20220116 snapshot updated all the above listed packages from snapshots 20220113, 20220114, 20220115 and 20220116.

I’m not a POWER (or recently: Power) expert, only an enthusiastic user and advocate. Still, in the past couple of weeks a number of people from around the world asked my opinion how the POWER architecture could be kept relevant. This blog is really just an opinion, as I do not have the financial means to go ahead. It is full of compromises some people are not willing to make. However, I think this is the safest and fastest way forward.

Why? Is there a problem?

Power 10 was just released, and used in some of the most powerful servers ever. Power became an officially supported architecture in major Linux distributions. Why do I talk about becoming irrelevant? Is there really a problem?

Well, it all depends on the perspective. IBM treats Power as an enterprise platform, just like mainframes. And as long as they run AIX and IBMi with a couple of proprietary commercial applications, they are right. However, as far as I know, a good part of Power boxes run Linux. And Linux is a volume play. The more users and developers work on a platform the better chance it has for survival. This is how 32 bit Power support was dropped many years ago from most distributions, even if some people still have Apple Macs and Genesi Pegasos boxes running. And this is how 64bit big-endian support was removed from mainstream distributions as well.

Power 9 had a huge momentum, in most parts software support for Power 9 is now in par with x86 and ARM. Unfortunately it is not enough to reach a momentum, it needs to be maintained as well. Raptor Computing did a fantastic job making Power more affordable. Those machines reached key developers in major projects. However their prices are going up due to supply chain issues and they do not plan on Power 10 any time soon (as it would require to use some closed source software components in the firmware).

The OpenPower foundation is planing to solve the volume play in its Power Pi project, but it is still years away. Currently there is no CPU that could be used on the planned $250 board and normally it takes 1.5 years or more to go from planning to a mass produced CPU.

You might say, that there are free resources available for open source developers. There is GitHub CI support for Power and various universities provide remote access to interested open source developers to Power servers. However most developers consider having a system on their desk locally as the best way to develop software. ARM and even RiscV have a huge advantage with the average developer now.

The Power architecture is handled as first class citizen in most major Linux distributions and even in FreeBSD, but by the time we have affordable Power hardware to grow the number of Power users and developers, many of them might already drop this level of support for Power.

Affordable hardware quickly

The previous section of my blog can be easily summarized in a single sentence in a TL;DR; style: we need affordable Power hardware quickly to keep and expand the momentum. Obviously it needs compromises as well.

Keep the dream alive

Old Macs are big-endian, just as network processors from NXP. Some Power developers still want big-endian systems to keep the dream alive. But support for big-endian systems is mostly gone from Linux distributions, and when it comes to developing common utilities or even programming languages, most developers are no more even aware that a world exists outside of little-endian. As much as I love the PowerPC laptop project, I see it now as a dead end: producing hardware for an ever shrinking software ecosystem.

Power 9

As much as I’d love to see a Power 10 desktop, I do not expect it to be affordable any time soon. Right now only 15 and 30 core variants are available for high end servers. Even if Power 9 is not so power-efficient and can be outperformed in some cases by some of the latest x86 CPUs, it is already available and at a relatively good price.

Not fully open source desktop board

Raptor Computing did a fantastic job at creating fully owner controlled boards where even the smallest bit of software controlling the board is open source. However even their smaller board is a full server board. Removing server components, like remote management capabilities, could bring costs down, just like components with closed firmware. My experience with firmware is that open source does not mean necessarily better, rather the opposite (yes, I am aware that this statement contradicts my title: open source evangelist).

I would not want to compete with IBM or Raptor Computing with server boards. Both have done their optimizations in enterprise manageability or having a fully open source stack down to the lowest level. On the other hand, while using a server board in the desktop technically works, simplifying it down to the desktop both on the hardware and software side can help to make it more affordable and thus reach more users. Hopefully a lot more users.

Roadmap

Obviously, creating a more affordable Power 9 board quickly is just a first step. It helps to reach more users and developers than the current IBM and Raptor Computing offerings. It also helps to make sure that efforts of the OpenPower Foundation are not wasted and Power support stays as first class citizen in major Linux distributions.

Power 10

I do not know the Power 10 CPU roadmap and if there will be any smaller versions of Power 10, but I really hope so. Those could be used in desktop systems once available.

Power Pi

Of course the ultimate target is a board that anyone can afford without thinking twice. Just like a Raspberry Pi. The Power Pi is planing to fulfill this idea. It might be here sooner or later than lower end Power 10 systems.

Libre-soc

The Libre-soc project is also building a Power CPU with many ground breaking ideas. Unfortunately a generally available version is expected to arrive even later than the Power 10 based desktop or Power Pi.

TL;DR;

Power itself is probably not in direct danger, but Linux and open source are definitely becoming an endangered species on Power due to the lack of a large active community. This situation could be improved with more affordable Power hardware. In short term a Power 9 board could be used for this purpose, on a longer term there are many open possibilities ranging from SoC to Power 10 (or later).

Obviously, my post only covers one aspect of a problem: keeping the open source community around POWER healthy. I have no idea about the engineering or financial side. I wonder about your opinion and if anyone will step up and implement something along these lines.

As you may know, YaST is not only a control center for (open)SUSE Linux distributions, but it is also the installer. And, in that regard, we think it is a competent installer. However, time goes by, and YaST shows its age in a few aspects.

During summer 2021, the team discussed how YaST should look in the near future. We considered many ideas, but let's focus on these:

• Shortening the installation process.
• Decoupling the user interface from YaST internals.
• Adding a web-based interface. We had WebYaST in the past, but it was not meant to work as installer.

We played around with these ideas (e.g., see $INSTALLER:80 and making openSUSE installer shorter), but we never had a concrete plan.

Fast-forward to December: before the holidays, we decided to resume our research and build a proof of concept of a web-based installer. We created something simple enough that, to be honest, does not even work at all. But after discussing the overall approach at a team meeting in January, we thought it might be a good idea to invest more time into it.

However, before jumping into coding just "something", we want to take our time to define the project in the right way, build a plan and ask for feedback.

It is not just about the user interface​

Providing an alternative web-based interface is just the tip of the iceberg. Before doing that, we need to make many internal changes, like decoupling the user interface code or adding a D-Bus interface.

Fortunately, we already have improved YaST internals in several vital areas (storage, networking, etc.). However, we are not there yet: a lot of work remains to be done.

The diagram below outlines the main components of the idea. Of course, it might change as the project evolves, but it looks good as a starting point.

Benefits​

Following this approach, we can foresee many benefits for YaST. To name a few:

• A better user interface: libYUI has served us well. However, it imposes some limitations that we would love to overcome.
• Reusability: YaST contains a lot of helpful logic that would be available to other tools.
• Better integration: It should be easier to integrate pieces of YaST in your own workflows by providing a D-Bus interface.
• Multi-language: Eventually, using D-Bus might allow us to use other programming languages.
• Contributors: We expect more people to contribute to the project by making the code more accessible and using widely-known technologies.

Q&A​

We expect you have questions, right? So let's try to anticipate some of them.

Are you deprecating the current user interface?​

No. We just want to offer an alternative and somehow simplified interface. Actually, we do not expect the web-based UI to be as powerful as the current one in the short term.

Which modules would get the new interface?​

At this point, we are limiting to the installer. We do not plan to add a web-based interface to any other module.

What about AutoYaST?​

Regarding AutoYaST, the idea is to use the same codebase as the standard installation while keeping the backward compatibility. So you could reuse your AutoYaST profiles with no significant issues.

Are you moving from Ruby to another language?​

No. We just thought that, in the future, it might be possible to reimplement parts of YaST (or write new pieces) in a different language. But we do not plan to replace Ruby in the short term.

When will it be released?​

We do not know yet.

Isn't precisely that what Anaconda developers are doing?​

Mostly yes. We were glad to read their announcement because it somehow validates our point of view about the future. But, of course, Anaconda is in a better position (e.g., it already features a D-Bus interface).

Would you rely on Cockpit?​

We do not know yet, but... why not? Cockpit is a really nice project and we have already released a module for Wicked. So perhaps we could seek some collaboration.

Why is called D-Installer?​

Well, it is just a play on words. We named the repository as "yast/the-installer" and, given that it is a service-based installer, it evolved to d-installer. Of course, not even the name of the project is set in stone, so we are open to better proposals. 😉

Conclusion​

We are in the early stages of an exciting project that should take us to redefine the future of YaST. And, of course, we would love to hear from you. So, please, do not hesitate to contact us if you have any comments or questions.

Have a lot of fun!

There is a new drop-in replacement for Elasticsearch, at least if you don’t mind the limitations and the alpha status. However, it definitely lives up to the promise that it provides an Elasticsearch-compatible API for data ingestion. I tested it with the elasticsearch-http() destination of syslog-ng, and it worked perfectly after I modified the URL in the configuration example I found.

So, what is Zinc? It is a search engine written in Go that provides an Elasticsearch-compatible API for data ingestion. You cannot use Kibana with it, only its own web interface. If you are not into graphs and dashboards, and want to search text messages, then it is perfect. The application itself is a single binary and it does not have any external dependencies. It is lightweight and easy to configure, as practically there are no configuration options at all.

Note: Zinc is still in alpha state. There are no guarantees that later versions will be compatible at any level. Error messages can sometimes be cryptic and you might run into unexpected behavior.

You can read the rest of my blog at https://www.syslog-ng.com/community/b/blog/posts/another-use-for-the-syslog-ng-elasticsearch-http-destination-zinc

The call for papers for openSUSE Conference 2022 is open!

The call for papers is open until April 14. This leaves a less than 90 days to submit a proposal. The dates of the conference are scheduled for June 2 - 4. The organizing team is preparing for a hybrid conference involving both virtual talks and live talks from the Z-Bau in Nuremberg, Germany. Registration for the conference has also begun.

Presentations can be submitted for the following length of time:

• Lightning Talk (10 mins) or Lightning Virtual Talk (10 mins)
• Normal Talk (30 mins) or Normal Virtual Talk (30 mins)
• Long Talk (45 mins) or Long Virtual Talk (45 mins)
• Workshop (1 hour) or Virtual Workshop (1 hour)

The following tracks are listed for the conference:

• Cloud and Containers
• Community
• Embedded Systems and Edge Computing
• New Technologies
• Open Source
• openSUSE

The conference already has two sponsors with Fedora and SUSE. Companies interested in sponsoring the event can view sponsorship information on the project’s wiki page.

Volunteers who would like to help with the planning of the event can join our planning meetings on Tuesdays at 19:00 UTC. Check the notes for details.

The start of an openSUSE survey has begun, and users, open-source contributors and community members are encouraged to take the annual survey.

Last year the community started its end of year survey and discussed the results during a community meeting.

The results and meeting feedback guided changes in the timing and format of the current survey, which is now open for people to take. Some changes were made to the previous year’s questions and the survey will run until Feb. 28.

The survey is expected to provide insights on how people view and interact with the project. The survey will also help the community better understand the growing use of openSUSE distributions and tools.

The survey was expected to start in December of 2021, but due to another survey about community safety and the elections timing of the openSUSE Board, a decision was made to begin the survey in the new year. Please help us by taking the survey.

Dear Tumbleweed users and hackers,

The holidays are over and people are returning to their computers, submitting a lot more than during the last weeks. Out of the 6 snapshots built and tested,5 made it out to the mirrors (0107, 0109, 0110, 0111, and 0112).

The most interesting updates in those snapshots are:

• Linux kernel 5.16.0
• GNOME 41.3
• openSSL 1.1.1m
• python36-FOO modulea re no longer built; The repo still contains ~ 200 python36 packages, but those are mainly due to build failures in python-singlespec packages. You can expect them to vanish over the next few days
• fmt 8.1.1: Restores ABI compatibiliy to fmt 8.0
• fwupd-efi: Re-add fwupdx64.efi.signed symlink (boo#1192206)
• KDE Frameworks 5.90.0
• KDE Plasma 5.23.5
• KDE Gear 21.12.1
• Mozilla Firefox 96.0
• Wayland 1.20.0

The first wave of submissions could be worked off and stagings are looking not that crowded at the moment. The things on the horizon I’m currently aware of are:

• linux-glibc-devel 5.16: syncing up with the kernel
• Ruby 3.1 to be introduced and become the main ruby interpreter. Ruby 2.7 and Ruby 3.0 will disappear at the same time.
• Python 3.6 interpreter will be removed (once all python36-FOO modules are gone)
• Python 3.10 as the distro default interpreter (a bit down the line)
• GCC 12 introduction has started to be as ready as possible for when the upstream release happens.

Most of those items will be some longer-lasting efforts. The list is ordered based on my prediction of how they will land in Tumbleweed.

Racing Destruction Set is a game released by Electronic Arts in 1985. It is a car and motocross racing game developed for the Commodore 64, and later released on the Atari 8-bit. At the time, this game was known for its innovative track editor and vehicle choice and customization. It was Electronic Arts’ third best-selling […]