For years, photographer Klaus Tröger built his professional workflow on a quiet contradiction; a Linux workstation running the Adobe software that most people assume belongs on a Mac or a Windows PC.

“I’m not willing to give up Linux, and I’m not willing to give up Adobe,” Klaus said. “So I stopped choosing.”

He has now carried that arrangement onto newer ground. Klaus recently migrated his longtime Debian machine to the beta release of openSUSE Leap 16.1 and has kept editing the whole time, running Adobe Lightroom, Camera Raw and Photoshop inside a Windows 11 virtual machine that never touches the local network directly.

The setup speaks to a small but persistent group of professionals who prefer Linux as their daily environment but cannot abandon Adobe Creative Cloud, whether for client work or long-established editing habits. Open-source alternatives exist, Klaus acknowledges, but they do not always fit an established business.

The hardware behind the system is deliberately dated, and Klaus says that is the point. Rather than chase current components at current prices, he chose Intel’s older LGA-1151 platform, pairing a Core i9-9900K, which is an eight-core, 16-thread chip from Intel’s Coffee Lake generation, with an Asus Z390 WS Pro mainboard. Each was a flagship in its day, he said, delivering strong benchmark performance from the processor and stability from the board. Because the WS Pro has grown rare and expensive, he notes the same approach works with a more common Asus ROG-STRIX Z390-F board and a six-core Core i7-8700K.

The board matters less for speed than for separation. To hand physical hardware to the virtual machine, Klaus relies on the Linux “vfio-pci” driver, which requires that the devices being passed through sit in their own IOMMU group, which is the system the hardware uses to isolate components from one another.

That requirement produces the workstation’s most surprising feature; two graphics cards from rival makers. An AMD Radeon RX 6600 drives the Linux desktop, while an Nvidia RTX 3060 is dedicated entirely to Windows. Contrary to a common assumption, Klaus said, modern Linux handles mixed AMD and Nvidia setups without conflict.

A dedicated graphics card is not optional for the Windows side. Adobe’s software needs a real GPU for post-processing. Software emulation will not do, and the card must clear a modest bar; it needs 1.5 to 2 GB of video memory, DirectX 12 compatibility and a driver no more than seven years old. Passing a qualifying card through to the Windows guest, in its own IOMMU group, lets Adobe applications run with near-native hardware acceleration while Linux remains in charge.

Most consumer mainboards make that separation difficult, Klaus said, because of how they share PCIe lanes and assign IOMMU groups. He offers two ways around it: use the Intel chip’s integrated graphics for the Linux host, the simplest and cheapest option for users with light rendering needs; or run two cards, placing the primary GPU in the CPU-managed first PCIe slot and the pass-through card in a slot managed by the Z390 chipset, which lands them in separate groups.

The rest of the machine follows the same divide-and-isolate logic. A separate USB controller goes to the virtual machine so Windows can have its own keyboard and mouse. Windows lives on its own fast NVMe solid-state drive. Klaus pins 10 processor threads to the host and six to the guest, splits 64 GB of memory evenly between them using huge pages, and swaps the default power daemon for the “tuned” tool set to a virtual-host profile.

He made one deliberate exception. Rather than assign the second NVMe drive straight to Windows, he keeps the guest in a disk-image file on an XFS partition.

“It’s so easy to just copy away the Windows file to get a backup,” he said.

The choice of host operating system was its own deliberation. Klaus had run Debian 13 for its stability. He found openSUSE’s rolling Tumbleweed release too bleeding-edge and Leap 15.6 too dated, which left the Leap 16.1 prerelease as a chance worth taking. The installation, using the Agama installer with an LVM disk layout and a Btrfs root filesystem for snapshots and rollback, produced what he called “zero surprises.”

Performance, he said, is nearly native. Virtualization always carries some overhead, “but it’s fully worth it.” Security is part of the appeal. Windows never sits directly on the local network; it operates behind the Linux host, shielded by the host firewall and additional controls. The arrangement, Klaus said, balances compatibility against exposure. Windows stays available for the few applications that demand it, while Linux runs everything else.

Asked what he would change if he built the machine today, Klaus did not hesitate. “None,” he said. His advice for photographers and power users eyeing a similar build comes down to one decision made early; choose the base hardware carefully, and confirm before buying that the components you intend to pass through can be cleanly separated by IOMMU group. Consumer boards, he warns, often cannot.

Terry Godier wrote a beautiful essay "The Boring Internet". The internet isn't dying, he argues, just the commercial veneer glued on top of it is. Underneath all the engagement metrics and algorithmic feeds, there's still an older, slower, more federated web. One built on protocols nobody owns. RSS feeds still work (thank you, Aaron), people can set up websites and blogs.

Lets start a webring in 2026

Don't worry, I haven't pushed too many pixels and gone a little cuckoo. But it's a fun exercise to remind what the web once was. We'll silently skip over the fact that I actually started using gopher first, but even web surfing didn't begin on a search engine back in the day. It was web rings, later followed by index sites.

Start

Not long ago I posted about designing app icons for 3rd party GNOME app developers. The post generated quite some buzz and some old and new faces started showing up to help with the backlog. So obviously I'd like to take you on a webring tour of all the designers responsible for making the GNOME app ecosystem a little less awkward to browse on Flathub.

Let me introduce you to Brage. He's been around for a couple of years now, helping to tame the flames of the reddit community, helping with the GNOME Circle project to improve the quality of GNOME apps in the wild, creating illustrations for initial states in apps, authoring some noteworthy apps himself. So thank you, Brage, welcome to the 90s!

Next Up: Brage Fuglseth

Dear Tumbleweed users and hackers,

Another rather uneventful week over here in Europe: another holiday in the middle of the week (for some regions, not all of Europe). The openSUSE community, in its international form, is usually not significantly affected by such interruptions and keeps rolling. That’s exactly what was observed this week as well: 6 snapshots (0529, 0530, 0531, 0601, 0602, and 0603) have been published over the last week.

The main updates contained therein were:

• Mesa 26.1.1
• Mariadb 11.8.7 & 11.8.8
• Qt 6.11.1
• Pipewire 1.6.6
• Samba 4.23.8 & 4.24.3
• GNOME 50.2
• util-linux 2.42.1
• gpgme 2.1.0
• java packaging change: migrated from update-alternative to libalternatives
• libvirt 12.4.0

The future is bright, and looking into my crystal ball (or on the staging dashboard) helps me to predict these changes coming to you soon:

• Mesa 26.1.2
• Linux kernel 7.0.11
• harfbuzz 14.2.1
• php 8.5.7
• KDE Gear 26.04.2
• KDE Plasma 6.7.0, currently 6.6.91 staged for QA
• Rework of Python3 packaging (as a meta package instead of a provides of the default interpreter)
• gcc 16 as the system default compiler

Do not let the AI to remove the fun part from software development. We shouldn't allow gen AI to write software just because it "can". First, we must ask if it "should" do it, and even then, we should ask if we want to delegate the fun part, the thinking, the writing, the learning.

Remember what's important, journey before destination, we are the Code:

Do not let AI to destroy the community, do not let it destroy the technological knowledge commons.

tl;dr

Open Source maintainers are dealing with a lot of new reports and pressure to "fix" the project due to generative AI.

We need to find a way of stopping this and get back to something maintainable before all maintainers get burned out and look for a job in a farm:

• 100% secure software doesn't exists, so there will be always a possible CVE there. As Spaf said in 1989:

The only truly secure system is one that is powered off, cast in a block of concrete and sealed in a lead-lined room with armed guards - and even then I have my doubts.

• Fixing bugs, adds new bugs, and if you need to fix something quick, the probability of new bugs will be higher. Do not forget about the First Law of Programming:

If it works, don't touch it

• The amount of CVE reports is lowering the CVE credibility and quality, so if everything is a "high" security issue, we can't prioritize now and these reports are not different from random issues in github. Do not listen to The Boy Who Cried Wolf

• Stable software is sable because it doesn't change too much. It's something that we are willing to loose trying to reach the impossible of 100% secure software?

The actual problem

There's a lot of money in AI tech right now, and everyone is trying to make the best gen AI tool or just pretend that their tool is the best.

In relation with the software analysis and writing, targeting the open source is the obvious strategy.

1. It's interesting to scrap every line of code, patch, pull request, issue and discussion around software to train your model, so AI scrappers are DDoSing open source projects infrastructure.

2. To promote their tools or themselves, Security Researches are using AI to target any project, reporting High security vulnerabilities, with the only goal of getting a CVE number to say how good they are.

This second point is affecting maintainers, because now you are receiving a lot of poor quality security reports, that are generated with AI and that looks plausible and are hard to read. You need to spend a lot of time to check if there's an actual wolf there or if it's again this boy that's tricking me.

This is burning the energy of maintainers, that instead of doing something productive are wasting their limited time talking with a Stocatic Parrot.

Do not let the AI Bros to use classic manipulation techniques on you!

A lot of open source projects are maintained by volunteers that do the work with passion and love. And even if it's the job that paid your bills, the maintainer can feel the pressure. When someone put a lot of love in something and work on it during years, it's part of his identity, so attacking the software is like attacking the person behind it.

This is nothing new, and a lot of people take advantage of this emotional link to manipulate the maintainer to do something that he do not want to do.

AI bros are using these techniques, do not let them to manipulate you and define your project agenda.

Here's a (not complete) list of known manipulation techniques that you can detect (and disarm!) in your daily community work:

• Flooding the queue. Just create so many new issues that the actual maintainers can't deal with it. You feel responsible for the project and feel bad because your TO-DO list is growing.

• This software is not secure (doesn't do what I want), I will use this other one instead that's better. The classic, "GNOME doesn't allow me to change this specific preference, I'll use KDE from now on".

• This software is low quality, it doesn't follow the (my random) quality standards. Direct attack to the maintainer self-esteem.

• Gaslighting software development. LLM are expert at this and people that uses it just copy the tactic. When the maintainer detects something weird and just tries to blame the other person for reporting nonsense and wasting all people time, it starts to invent new arguments and ignore the previous interaction.

So, take it easy, and remember the best clause in almost any software project, THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU:

Disclaimer of Warranty.

THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT
WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND
PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE
DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR
CORRECTION.

Is the software more insecure in 2026?

No. Anyone old enough could remember how insecure old software was. Do you remember windows 98? Do you remember the internet when everything was http (without that little s at the end), when people use ftp to logging into their server and modify the php code directly on production?

It's true that today we have more dependency on technology, but it's also true that everything is more secure, we have more and better cryptography, we have different levels of isolation, virtual environments, containers, virtual machines...

But we have the feeling that since AI can analyse all the software and look for vulnerabilities, we are doomed, because any stupid kid can hack my over engineered GNU/Linux machine!

First, that's not true, you need to know about security to get something useful from any AI tool. But even if it was true, what can you do about it? We need to be practical and find a balance between risk and usefulness, so do not overestimate the risk just because everyone is talking about it right now.

But even then, the security paranoia is not good for anyone. Software is inherently buggy, people write software and makes mistakes, so a possible vulnerability appears. In theory, these bugs are fixed when discovered, so it's always recommended to update to the latest version, because almost all known bugs will be fixed.

But it's also known that new versions comes with new functionality and code, and that means new "unknown" bugs or different behavior. That's a headache, so that's why the stable and Long Term Support are popular distributions, because "if it works, don't touch it".

Stable packages just get the fixes, not new features, but fixes are also code changes, so there's always a possibility to break something, even with a patch update.

The stable software has a lot of value, do not let the AI security paranoia destroy that, and convert everything in a rolling release with the latest and greatest (and possibly broken) software. Sometimes it's better to keep using something old, with known vulnerabilities that you can mitigate, than use the latest with unknown new vulnerabilities that you can't do anything about.

I will fight AI with AI

Please, do not do that. What I was trying to argue during this long post is not a technical problem. The current burnout problem in open source is a social problem, you can't fix it with a new layer of probabilistic tokens.

• Community reaction against AI. The current industry push for the usage of AI everywhere is affecting a lot of people, and as a reaction a lot of people are directly fighting back. Using gen AI just sends the message that you do not care enough to do it yourself, and destroy the trust on the project.

• It doesn't worth it. Even if the AI works (that it doesn't) it doesn't worth it. Writing code is easier than reviewing, you learn and grow with every new line of code that you write, delegating the fun part and personal growth part to an AI will make you work more miserable and you will be a junior forever.

• It doesn't create community. Think about it, it's hard to get someone involved in a software project, but who will want to read or improve the code produced by a gen AI? The only future collaborator will be another AI.

Take it easy

Just remember, you can always say no, there's no hurry, and there's no need to work on something that you don't want just because other people consider that important.

Free Source is something done by people, for people. The software is important, but the community around it is sometimes more important. We use Free source not because it's technically better (that it is), but because we trust who, how and why are writing it.

Remember why are you doing this, do not remove the Fun part, continue with the Just for Fun mood.

Every time a piece of software encounters a new access pattern, the answer is to tweak the policy. Then tweak it again. Then tweak it again. Then tweak it again. Then tweak it again. At what point does this stop being a security model and start becoming an endless process of granting exceptions?

There is one thing in open source software that consistently consumes more time than it has any right to.

SELinux.

Every few weeks it seems like another SELinux issue appears.

Implementing a new feature? Fix SELinux. Fixing a bug? Fix SELinux. Scratching your butt? Gotta fix your SELinux policy. Repeat forever.

At some point we should start asking the question: What exactly is this accomplishing?

The Concept

The idea is straightforward. If an attacker compromises a process, SELinux limits what that process can access. The attacker is confined to a security domain and prevented from reaching resources outside that domain.

That’s a reasonable goal.

I’m not arguing against the idea of mandatory access control. I’m questioning whether this was the right tradeoff.

The Cost of Convergence

If a piece of software has been around for twenty years, and enough users have run into enough denials, and enough maintainers have added enough exceptions, then sure, maybe the policy eventually becomes stable.

But what a ridiculous way to get there.

The model seems to be: run the software, wait for SELinux to break something, examine the denial, add a rule, repeat until users stop complaining.

That’s not design. That’s playing whac-a-mole.

We’re not thoughtfully defining a security model. We’re painfully discovering the application’s behavior by tripping over every possible thing it might need to do.

An Engineering Failure

SELinux asks us to accept that defining a security model requires years of stumbling over ourselves. I have a hard time believing that’s the best we can come up with.

Surely there must be a middle ground somewhere between “the application can do anything it wants” and “the application can’t do anything until we’ve spent the next several years teaching SELinux how it works.”

At some point we should be willing to ask whether there is a better way to solve this problem.

I don’t have the answer.

But I’m no longer satisfied with pretending that SELinux is the answer.

openSUSE.Asia Summit 2026 Logo Competition

We are excited to announce the launch of the openSUSE.Asia Summit 2026 Logo Competition!

The Summit logo is more than just a symbol—it represents the energy, creativity, and diversity of our openSUSE community across Asia. This year, we invite you to make history by designing a logo that will become the face of the 2026 Summit.

The Summit will take place at the Teaching Industry Learning Center (TILC), Vocational School, Universitas Gadjah Mada (UGM), Yogyakarta. More event details will be shared soon. The logo competition is now open and will close on 21 July 2026. The winner will receive a special “Geeko Mystery Box” from the organizing team!

Submission Deadline: 21 July 2026 Winner Announcement: 3 August 2026

Contest Guidelines

1. License: The logo must be licensed under CC-BY-SA 4.0 and allow everyone to use it without attribution if selected. Attribution will be displayed on the Summit website.
2. Originality: Your design must be original and free from third-party materials
3. AI: AI generated content is strictly prohibited.
4. Formats: Submit both monochrome and color versions.
5. File Format: Only SVG files are accepted.
6. Community Spirit: The logo should reflect the openSUSE community in Asia.
7. Prohibited Elements: Do not include trademarks, inappropriate or offensive content, violence, discrimination, political or religious imagery, or any content violating openSUSE values.
8. Trademark: Follow the openSUSE Project Trademark Guidelines.
9. Branding: Refer to the openSUSE branding guidelines for inspiration (optional).

How to Submit

Send your design to opensuseasia-summit@googlegroups.com with the following details:

Email Subject: openSUSE.Asia Summit 2026 Logo Design - [Your Name]

Attachments:

1. Vector File: The logo in SVG format ONLY (Refer to template in Figure 1).
2. Bitmap File: A PNG version (minimum 256x256 pixels).
3. Design Philosophy: A short TXT or PDF document explaining your concept.
4. File Size: Ensure all files are under 512 KB.

Figure 1. Sample SVG Template for the logo

All submissions will be reviewed by the Summit Committee. Note: The final decision will be made by the committee and may not necessarily be the highest-voted design.

Tip: Use Inkscape, a free and open-source vector design tool!

Let your creativity shine and help shape the identity of openSUSE.Asia Summit 2026. Good luck!

OpenSSL 4.0 was released just over a month ago. So, how is its support progressing in syslog-ng? Well, Git master already supports it, and the patch is easy to backport to earlier releases. At the same time, version 4.12 will support OpenSSL 4.0 out of the box.

A month ago, someone from Gentoo Linux reached out to the syslog-ng team about OpenSSL 4.0 support. I asked the community about their expectations, knowing that version 4.0 is not an LTS version. However, I quickly learned that all major distros were preparing to use it in their rolling development versions. A few days later, we also received hints on how to add support for it in syslog-ng. And thus, a PR was born, which is now merged into syslog-ng git master.

What does this mean for you?

• If you need OpenSSL 4.0 support RIGHT NOW using a RELEASED syslog-ng version, then use syslog-ng 4.11 and the related pull request from https://github.com/syslog-ng/syslog-ng/pull/5688
• Use the latest syslog-ng git snapshot, as the above PR is already merged.
• Wait a few more weeks, as syslog-ng 4.12 will be released soon with OpenSSL 4.0 support.

Originally published at https://www.syslog-ng.com/community/b/blog/posts/the-status-of-openssl-4-0-support-in-syslog-ng

The Travel Support Program (TSP), which is aided through donations to the Geeko Foundation, is now accepting applications for the openSUSE.Asia Summit 2026.

Funds are allocated by the foundation specifically for travel assistance for speakers attending the event.

Applications for the TSP are open now and will run until July 31, which will follow an announcement related the Call for Papers.

People whose talks are accepted can submit a request at tsp.opensuse.org.

The TSP exists to ensure financial constraints don’t prevent passionate contributors and community members from participating.

The openSUSE.Asia Summit 2026 organizers of the summit encourage you to apply early.

For questions about the TSP process, visit the wiki for more information and read the Geeko Foundation’s travel policy.

Further details will be shared later about the event planning, so please pay attention to announcements for the summit.

We look forward to seeing you there!

For more details on openSUSE.Asia Summit 2026, visit events.opensuse.org.

Not the best film ever, but in today's Hollywood landscape it's a rare breath of fresh air. Kane Parsons takes the internet meme concept he started on YouTube and actually makes a feature-length film that's doing great at the box office.

The mood is great. That unsettling stillness of these generic liminal spaces. For something that builds a feeling / mood, the flick would benefit from a butcher in the editing room. I'd probably still not give it the extra star, but this really isn't the kind of movie that needs the extra 20 minutes.

Biggest entertainment was definitely watching my son freak out in the third act. :)

★★★★☆