Planet Debian Derivatives

Volumio: How to Organize a Digital Music Library Well

Volumio — 2026-08-07T00:06:21+00:00

A music library becomes frustrating long before it becomes unplayable. It starts with two copies of the same album, an artist filed under three different names, a compilation scattered across the alphabet, or a beautiful high-resolution release that appears with no cover art. Learning how to organize digital music library files is less about making every folder look perfect and more about making every listening session feel effortless.

For a serious collection, organization also protects the work you have put into acquiring music. Clean metadata makes an artist catalog easy to explore, reliable backups keep rare files safe, and a consistent structure helps a network player index your library correctly. The goal is simple: all your music, ready when you want it, without hunting through file names or switching between sources.

Start with one master library

Before changing tags or moving folders, decide where the authoritative version of your collection will live. This is your master library: the place you update when you add an album, correct an artist name, or replace a low-resolution file with a better release.

For a smaller collection, an internal computer drive may be enough. For larger libraries or a system used by more than one listener, a dedicated external drive or network-attached storage device is often the better choice. A network location allows compatible music players to access the same collection without leaving a computer running in the listening room.

Avoid maintaining several active versions of the library on different drives. It seems convenient until one version has corrected artwork, another has new purchases, and neither is complete. Keep one master, then create backups from it.

A practical folder structure is straightforward:

“`text Music/ Artist Name/ 1997 – Album Title/ 01 – Track Title.flac 02 – Track Title.flac “`

This format is readable, portable, and useful even if you later use different playback software. Including the year before an album title helps distinguish multiple releases with similar names and keeps an artist’s work in a sensible order when browsing folders.

For box sets, live recordings, and deluxe editions, consistency matters more than a single universal rule. You might use `2019 – Album Title (Deluxe Edition)` or place discs in `CD1` and `CD2` subfolders. Choose a convention you can remember and apply it going forward. You do not need to rebuild your entire library in one weekend.

Let metadata do the real organizing

Folders provide a foundation, but metadata is what makes digital music enjoyable to browse. Your player uses embedded tags to group tracks into albums, identify artists, sort composers, display artwork, and build views by genre or date. A perfectly named folder cannot compensate for incomplete or conflicting tags.

At minimum, check these fields for every album: album artist, artist, album title, track title, track number, disc number, release year, genre, and embedded cover art. For classical, jazz, and other repertoire where the performer is not always the primary point of entry, composer, conductor, ensemble, and work tags can be equally valuable.

The distinction between Artist and Album Artist prevents many common library problems. For a standard studio album, they may be identical. For a guest appearance, the track artist can include both performers while the album artist remains the main artist. For compilations, set the album artist consistently to `Various Artists`. This keeps one soundtrack or anthology together instead of creating a separate album entry for every track performer.

Be deliberate with artist names. `David Bowie`, `Bowie, David`, and `David Bowie feat. …` can all become separate entries. Use one preferred spelling for the artist field, and reserve featured artists for the track title or a dedicated contributing-artist field if your tagging application supports it.

Keep genres useful, not theoretical

Genres can either help you choose music or become a cloud of near-duplicates. If your collection includes `Rock`, `Alternative Rock`, `Alt Rock`, `Indie Rock`, and `Indie`, that may be exactly right if you browse by those distinctions. If you never do, it creates noise.

Use a limited set of genres that matches how you listen. Many collectors are well served by broad categories such as Rock, Jazz, Classical, Electronic, Folk, Soul, Hip-Hop, Pop, Country, and World, with a few carefully chosen subgenres where they matter. The right system depends on your collection and your habits, not on a database’s idea of precision.

Choose formats and protect sound quality

A library can contain several formats, but it helps to know which files are your archival masters. Lossless formats such as FLAC and ALAC preserve the full audio signal while allowing metadata and artwork to travel with the file. WAV can sound excellent, but its metadata support is less consistent across software and devices. AIFF is another lossless option with stronger tagging support than WAV in many environments.

Lossy files still have a place. A well-encoded AAC or MP3 file can be useful for a car, portable player, or a legacy device with limited storage. The key is not to confuse a convenience copy with your master. Keep the lossless original, then create portable copies only when you need them.

Do not upsample or convert a lossy file to a high-resolution format expecting more detail. It produces a larger file, not more musical information. When possible, replace poor-quality files with a genuine lossless or high-resolution source instead.

Handle album art with care

Album art is part of the pleasure of owning music. It also makes a library far easier to navigate from across the room. Use a square image with enough resolution to look clean on a tablet, television, or music player display. Around 1,000 by 1,000 pixels is a sensible target for most collections.

Whenever possible, embed the artwork in the audio files themselves. You can also keep a `cover.jpg` file in each album folder as a fallback for systems that read folder art. Embedded art is generally more portable, while a folder image can be simpler to replace across a whole album. Using both is reasonable if storage space is not a concern.

Avoid placing unrelated scans, PDFs, and image files in the same album directory unless you know your library software handles them well. Booklets can be worth keeping, especially for classical releases and box sets, but a separate `Booklets` folder beside the music library may keep scanning and indexing cleaner.

Treat compilations, classical, and multi-disc albums as special cases

These are the releases most likely to expose inconsistent tagging. For compilations, use `Various Artists` as the album artist, retain the individual performer in the artist field, and make sure the album title is identical on every track. Include disc numbers for multi-disc sets even when there is only one disc in most of your library. That small habit prevents track 1 from disc two appearing directly after track 1 from disc one.

Classical organization is more personal. Some listeners browse by composer first, while others choose by performer, conductor, orchestra, or work. There is no wrong answer, but your tags should support the route you actually take. A useful approach is to set the album artist to the principal performer or ensemble, complete the composer field carefully, and format track titles so the work and movement remain clear. Consistent work and movement tags become especially valuable in large collections.

Live albums deserve equally clear labeling. If an album has both studio and live versions, include the venue, city, or `Live` designation in the album title rather than relying on a vague folder name. Future you will be grateful.

Build listening paths, not just a database

Once your core tags are clean, add organization that reflects the way you spend time with music. Favorites, recently added albums, five-star records, and playlists can turn a large library from an archive into a living collection.

Keep playlists purposeful. A playlist for late-night jazz, a Sunday-morning selection, a reference set for evaluating a hi-fi system, or a road-trip sequence is more useful than hundreds of abandoned queues. For long-term portability, consider saving playlists in a widely supported format such as M3U8 and use relative paths when possible. Relative paths are more likely to keep working if the storage device changes location.

This is also where a unified music-player ecosystem earns its place. A platform such as Volumio can bring local files, connected storage, and supported streaming services into one interface, so browsing a cherished download and playing a new discovery feel like parts of the same experience. Good organization makes that unified view more accurate and more enjoyable.

Back up before you trust the cleanup

Editing tags is usually safe, but moving folders, batch-renaming files, and replacing artwork can create mistakes quickly. Back up the master library before any major cleanup, then keep at least one additional copy on a separate drive. For truly irreplaceable purchases, recordings, and personal transfers, keep another copy away from the home as well.

The familiar 3-2-1 approach remains sensible: three copies of your data, on two different types of storage, with one copy stored elsewhere. Your playback library does not need to be complicated, but it should not be the only place your music exists.

After making changes, rescan your music player and inspect a few problem areas: compilations, albums with featured guests, multi-disc sets, and classical recordings. Correcting a handful of edge cases reveals whether your system is working before you apply it to thousands of tracks.

Make organization a small ongoing habit

The best library is not the one with the most elaborate taxonomy. It is the one you can maintain. When a new album arrives, check its metadata, artwork, format, and folder placement before adding it to the master collection. That takes a few minutes and prevents a pile of unfinished work months later.

Leave room for exceptions. A rare bootleg, an archival radio session, or an unusual composer credit may not fit your rules neatly. Give it the clearest information you have, preserve the music, and return to listening. A well-organized library should make the path to a favorite record shorter, then get out of the way.

The post How to Organize a Digital Music Library Well appeared first on Volumio.

Deepin: (中文) 7月社区月报｜deepin 25.2.0 镜像发布 & 小U同学定时任务上线

xiaofei — 2026-08-06T10:31:12+00:00

Sorry, this entry is only available in 中文.

Volumio: Choosing a Music Streamer With TIDAL Connect

Volumio — 2026-08-06T08:21:48+00:00

The appeal of a music streamer with TIDAL Connect is immediate: choose an album in the TIDAL app, select your hi-fi system from the device list, and let the streamer take over playback. Your phone becomes a remote rather than the source of the audio. That distinction matters when your system has been assembled carefully, from the network connection to the DAC, amplifier, and speakers.

For many listeners, TIDAL Connect is the missing link between the streaming service they enjoy and the listening experience their equipment deserves. But the badge alone does not make every streamer the same. Sound quality, local-library support, control options, hardware design, and the quality of the streaming platform all determine whether a player will feel at home in your system for years.

What TIDAL Connect Actually Does

TIDAL Connect lets a compatible network player receive music directly from TIDAL’s servers after you initiate playback in the TIDAL app. Once music is playing, the streamer handles the stream itself. You can use your phone for other tasks, leave the room, or even close the app without turning it into an audio transport tethered to your system.

This is different from basic Bluetooth playback, where the phone remains central to the audio path and may apply its own limitations. It is also different from screen mirroring or a generic cast feature that may not expose the same playback information or sound-quality options. With TIDAL Connect, the familiar TIDAL interface stays in front of you, including its albums, playlists, editorial recommendations, and search, while the dedicated player does the serious work of delivering music to your DAC or integrated amplifier.

That convenience is valuable, but it should be understood as one part of a streamer rather than the whole product. A great listening system needs more than a good handoff from an app.

Choosing a Music Streamer With TIDAL Connect

Start with the role the streamer will play. If you already own a DAC you love, a digital transport with a well-implemented USB, coaxial, or optical output may be the right answer. It keeps conversion in the DAC and focuses the streamer on network playback, clocking, power delivery, and a clean digital signal.

If your current system has open inputs but no DAC, a streamer with a built-in converter can reduce box count and simplify setup. This can be an excellent route for a secondary system, a desktop setup, or a living room where elegance matters as much as capability. The trade-off is flexibility: an external DAC makes later upgrades easier, while an integrated design is often more compact and direct.

Also consider whether the player supports the connections your system actually uses. USB is common with modern DACs, but coaxial and optical remain useful, particularly with established hi-fi components. Balanced analog outputs can make sense when connecting to a balanced preamp or active speakers, while standard RCA outputs remain the practical choice for many integrated amplifiers. More connections are not automatically better. The right connections are the ones that avoid adapters, work reliably, and suit the equipment you already enjoy.

Native TIDAL control and a unified music experience

TIDAL Connect is ideal when you want to browse TIDAL exactly as TIDAL presents it. Yet most serious listeners do not live entirely inside one streaming app. They may have a NAS full of carefully tagged albums, a USB drive of purchases, internet radio favorites, and subscriptions to more than one service.

A streamer with its own strong music-management environment adds value here. It should make local music feel like a first-class source, not an afterthought hidden behind folders. It should also offer a clear mobile or web interface for times when you want to queue music from several sources, adjust playback settings, or explore your own collection without switching devices.

This is where ecosystem design becomes personal. Some listeners want the TIDAL app to remain their main command center. Others want one place for TIDAL, local files, web radio, and other services. The best choice is not the one with the longest feature sheet. It is the one that matches the way you discover, organize, and return to music.

Sound quality depends on the whole chain

A TIDAL Connect logo confirms compatibility, not a guaranteed sonic result. Network hardware, power supply design, digital output implementation, DAC quality, and system matching still matter. So does the recording. A revealing streamer will not turn every master into an audiophile release, but it can make a well-recorded performance more immediate, stable, and emotionally convincing.

If possible, listen through your own system or one close to it. Pay attention to the qualities that matter over a full album: the natural decay of a piano, the separation of voices in a dense mix, the weight and timing of bass, and whether brighter recordings remain listenable. Quick comparisons can favor exaggerated detail. Long listening often reveals the value of balance, low noise, and freedom from fatigue.

Resolution support deserves the same clear-eyed approach. TIDAL offers a range of audio formats and quality levels, and compatible playback can vary with the device, subscription, release, and software implementation. A streamer should handle the formats relevant to your listening, but format support should not distract from fundamentals. Reliable playback and musical coherence will matter more than a specification you rarely use.

Network Setup Is Part of the Product

Streaming is only as dependable as the connection feeding it. Ethernet is usually the straightforward choice for a fixed hi-fi rack, particularly where Wi-Fi signal strength is inconsistent. A wired connection can reduce variables and provides welcome confidence when you are settling in for a long evening of music.

Wi-Fi can still be an excellent option when running a cable is impractical. Place the streamer where it has a stable signal, avoid crowding it with network hardware or metal obstructions, and make sure the router is capable of serving the rooms where you listen. If playback skips, drops from the device list, or takes too long to start, investigate the network before assuming the audio component is at fault.

A good streamer should also feel approachable during setup. You should be able to connect it to the network, install updates, name the device, and begin listening without becoming an IT administrator. At the same time, advanced listeners benefit from meaningful settings for output mode, volume behavior, library scanning, and digital processing. The art is making those controls available without making them mandatory.

Consider the Life of the Streamer After Purchase

Unlike a turntable or a traditional amplifier, a network streamer is partly defined by software that will evolve after it arrives. Streaming services update their requirements. Mobile operating systems change. New playback features appear, while occasional bugs need attention. Look for a platform with a clear history of support, active development, and an engaged user community.

This is especially relevant for builders using a Raspberry Pi or PC-based player. DIY can be remarkably rewarding: it lets you choose your enclosure, power approach, storage, and DAC while learning exactly how the system works. But it also asks for a little patience. A dedicated streamer trades some of that experimentation for a finished, purpose-built component designed to live comfortably in a hi-fi rack.

Volumio offers both paths, bringing local libraries, streaming services, and connected audio devices into a single music-player ecosystem, whether you prefer to build a player or choose hand-assembled Italian hardware. That flexibility is useful because a first streamer is rarely the last word in a music system. Systems change, collections grow, and listening habits develop.

The Small Details That Make Listening Easier

Before buying, think about daily use rather than only the first setup. Will the streamer wake quickly? Can everyone in the household select music without asking for help? Does the display, if included, show enough information from across the room? Can you control volume safely if the streamer feeds a power amplifier directly?

Multiroom capability may matter if you want the kitchen, office, and main system to share music, though it is worth checking how it works with the services you use most. Gapless playback matters for live recordings, classical works, and albums designed as continuous performances. A responsive queue matters whenever an evening moves from intentional listening to spontaneous requests.

These are not glamorous specifications, but they shape whether a component becomes part of your routine. The finest DAC architecture is less satisfying if the player regularly loses its connection or makes your own library difficult to find.

Choose the streamer that makes it easier to press play on the records you already love, then leaves enough room for the next musical obsession to find you.

The post Choosing a Music Streamer With TIDAL Connect appeared first on Volumio.

GreenboneOS: Patch Now! CVE-2026-18577 in N-able N-central Actively Exploited

Joseph Lee — 2026-08-06T06:47:52+00:00

CVE-2026-18577 (CVSS 8.2, EPSS ≥ 71st pctl) and CVE-2026-18556 (CVSS 7.4, EPSS ≥ 19th pctl), published in early August, have both been added to CISA’s Known Exploited Vulnerabilities (KEV) list within days of their disclosure [1][2]. N-able has published Indicators of Compromise (IoC) and post-exploitation activity from successful attacks against its own hosted N-central instances. […]

Univention Corporate Server: From Nubus to an Automated Linux Desktop: A Case Study from pro mente tirol

Vanessa Knoop — 2026-08-05T09:28:03+00:00

A social services organization in Tyrol, 24 locations, and the conviction that our data belongs in our own network: Here’s how we put that principle into practice with Nubus and Ubuntu.

Since 2014, I have been heading the IT department at pro mente tirol, a non-profit organization providing social psychiatric services for people with mental health conditions. We operate 24 locations across Tyrol, employ around 300 people, and are 100% publicly funded. At some point, Windows 7 reached the end of its lifecycle. The question was: Should we move to Windows 10 or should we consider something different for the desktop? I’ve been an open source enthusiast since my university days, so we decided to explore an alternative.

In this article, I’ll explain how, together with Siedl Networks, we made the transition from Windows to Ubuntu, using Univention Nubus as our Identity & Access Management foundation, Ansible for automation, and custom Python scripts to configure network shares. I’ll also explain what the migration cost, how our employees responded, and how we organized support after each site migration.

Our Data, Our Infrastructure

Before deciding which operating system our employees would use, we first had to answer a much more fundamental question: Where should our data reside, and who should control it? Our management’s answer was clear: As much data as possible should remain within our own network. We do not rule out external solutions, but we carefully evaluate where the servers are located.

The second strategic decision was not about the infrastructure but about the applications themselves. Early on, we decided to move as many applications as possible into the browser. Today, most of our applications run as web applications, including email, document management, collaboration tools, and client documentation. Locally installed software is essentially limited to a web browser, LibreOffice, and printer drivers. That gave us considerable flexibility when choosing a desktop operating system because the more runs in the browser, the less it depends on the operating system itself.

That flexibility ultimately became our opportunity. Windows 7 had reached end of support, and around 220 PCs needed to be replaced or upgraded. At standard market prices, new hardware and software would have cost us around €170,000. Even with discounts available to non-profit organizations, the total would still have been approximately €120,000. To be fair, obtaining those discounts involves a significant amount of administrative work: forms, proof of non-profit status, and the same paperwork every year. It all ended up on my desk.

In the end, our migration to Linux cost around €15,000, including my own working time and the development work carried out by Siedl Networks. And there’s more: We were able to keep around 90% of our existing hardware. We installed a few SSDs, added RAM where necessary, and occasionally replaced a power supply.

Ubuntu as Our Linux Desktop: Why We Chose It

Linux Mint, Zorin OS, and a dozen other distributions, we’re often asked why we didn’t choose one of those instead. As an administrator, one factor stood out above all else: Ubuntu is the most widely used Linux distribution. There’s a good chance that some employees have already encountered it at home. That’s preparation I don’t have to do myself.

Ubuntu is also backed by a large online community, including a very active German-language forum that provides answers to many user questions. In addition, Ubuntu includes much of what we need out of the box. It was important to me that we install as little additional software as possible.

For us, 2018 was the year of preparation. We defined the core principles that would guide everything that followed.

From Nubus and Ansible to an Automated Desktop

At pro mente tirol, Nubus is the central control point for desktop management, and LDAP groups are the key to making it work. We first create a group in Nubus, then create a network share, and finally assign that share to the group. The reason is simple: We work with team accounts, not individual user accounts. Which network drives someone sees depends on their group membership, not on an individual user account.

When setting up a workstation, we still perform several tasks manually: installing the operating system, configuring SSH remote access, setting up printers, and installing remote support software. These tasks cannot be meaningfully automated because they depend on the individual location. We then join the PCs to the UCS domain. Only at that point does the system know that the computer exists and can assign it to the appropriate groups, shares, and permissions.

After that, Ansible takes over. The playbooks install all required packages, including software for accessing Samba network shares and a LibreOffice build from our own Personal Package Archive (PPA) repository. The Snap version of LibreOffice provided with Ubuntu also includes help and developer files, which noticeably slows startup on older hardware, although this is hardly noticeable on newer machines. Using our own PPA also means we are not dependent on Canonical’s package maintenance and receive updates directly from the software vendor.

The Ansible playbooks also deploy a variety of configuration settings, including the browser’s home page and extensions, history and cache behavior, and the default application for opening PDF files.

A custom-developed Python script then reads the directory service to determine which network shares are assigned to which groups. Based on this information, it automatically generates two files: a bookmarks file for the Nautilus file manager so that network drives appear in the sidebar, and a configuration file that automatically mounts the Samba shares when users log in, just as Windows users are accustomed to after signing in to a domain.

During the very first login, users must sign in twice. The first login checks the network drives; after the second login, everything is in place: bookmarks, application shortcuts, assigned network drives in the file manager, and the taskbar. From then on, everything is configured automatically each time the user signs in. Even if someone rearranges their icons, they’ll be back in the expected places after the next login.

For asset management, that is, keeping track of our devices, we initially experimented with Landscape, Canonical’s commercial management solution. After two years, we switched to a leaner approach: our own Cockpit server, which provides an overview of all our devices. The same server also runs Ansible for automation.

Linux in Everyday Work: What Our Users Had to Say

Office compatibility was initially one of the key topics for our support team. During the migration phase, Linux users could access a Windows environment with Office 365 via a Terminal Server if they ran into problems with a document. We have since discontinued this access: users have not needed it for around four years. We now handle the remaining compatibility cases using OnlyOffice in our Nextcloud.

And we approached the issue from the other direction as well: all Windows PCs now use the ODF open file format as the default, so our Windows colleagues also create ODT and ODS files. For remote access to virtual desktops, we now use KASM, which replaced Guacamole. Since the beginning of 2026, we have no longer provided Windows desktops there either.

What surprised us positively was the feedback on performance. Logging in is faster and applications start more quickly—even on older hardware. Our users mentioned this repeatedly. One of our employees told us that they no longer go for a coffee while waiting for their PC to boot.

The look and feel of the new environment was not a problem for most people. One employee, for example, said that the interface felt pleasantly neutral. Another commented that working with it was just like working on her Mac. Of course, there are other opinions as well, and some users still consider Microsoft indispensable, but those critical voices are becoming fewer and fewer.

Rollout Across 24 Locations: Preparation, Support, and Follow-Up

We started the first rollouts in 2019. We proceeded one location at a time, from Reutte to Landeck, then Imst and Schwaz, all the way to Kufstein and Lienz. By late summer 2020, all PCs scheduled for migration had been converted. In 2021, we then quickly upgraded all systems from Ubuntu 18.04 to Ubuntu 20.04. Since the end of 2024, all of our Linux PCs have been running Ubuntu 24.04.

The next Ubuntu upgrade, however, will have to wait a little longer. Ubuntu 26.x uses Wayland by default, and that creates a problem for our support team. When issues arise, we often log in to employees’ desktops unattended in order to investigate them directly. Wayland does not easily allow this: screen sharing and remote input require a consent dialog that the logged-in user must confirm every time. That simply does not work when a workstation is unattended or still at the login screen.

The rollout process for employees was always essentially the same. Around one month before the migration, we contacted the respective team and scheduled a meeting. Two or three hours in which we explained what they could expect: what the new desktop would look like, which applications they would find, where compatibility issues might occur—and why we were making the change. We showed the cost comparison, talked about data security, and explained the reduced attack surface compared to ransomware. Those are convincing arguments, even for employees who are not particularly interested in IT.

After the migration, we dedicated ourselves exclusively to that team for two weeks. All other tickets were put on hold so that the priorities were clear. Anyone who encountered a problem contacted us and received immediate support.

At the same time, we established a tiered support model: first look into the issue yourself, then ask your colleagues, and only then call IT support or open a ticket. In some teams, a technically minded person naturally emerged as the first point of contact, collecting questions and passing them on to support, a welcome side effect. The better a team works together, the more people help one another, and we have experienced that time and again over the years.

From the Desktop to the Portal: Where the Journey Is Headed

The move from Windows to Ubuntu was only half the story. Equally important was the parallel transition from locally installed applications to web applications.

The portal is now the central point of entry: our employees sign in once via Single Sign-on and then have access to all applications assigned to them, regardless of whether those applications are hosted internally or externally.

The role-based system behind it makes administration much easier. Which tiles someone sees in the portal depends on their group membership, the very same logic we already use for our network shares. New employees automatically receive access to the right applications without us having to configure every account individually.

The more applications we can integrate in this way, the less depends on the individual desktop computer. The portal becomes the actual workspace and the operating system underneath becomes secondary.

Nubus and Linux Desktops: What We Learned

The move to Linux desktops for our employees has been a success. I don’t say that because everything went smoothly, but because we were able to deal with the problems that arose. The performance improvements were real and immediately noticeable. The costs were significantly lower than those of a Windows upgrade. And we were able to continue using around 90% of our existing hardware.

What we underestimated was Office compatibility during the initial rollout phase. We also underestimated the fact that the open source world is constantly evolving something that often remains invisible to users but regularly creates additional work for administrators.

Our most important lesson, however, is this: If you bring your employees on board before the first PC is migrated, you will face much less resistance later on.

Our data stays with us. Our infrastructure belongs to us. That was the fundamental decision – and it still is today.

One open question for the community: the Wayland issue is currently preventing us from moving to Ubuntu 26.x. If you manage a similarly distributed Linux environment and have already found a solution without sacrificing security features, we’d be happy to hear from you in the comments below this article.

Der Beitrag From Nubus to an Automated Linux Desktop: A Case Study from pro mente tirol erschien zuerst auf Univention.

Purism PureOS: Making Videos With Absolute Freedom

Purism — 2026-08-05T07:37:51+00:00

As with every video that we make at Purism, we have made the Librem 16 launch video in house with Librem hardware running PureOS, and using free software only. This blog post will give a quick overview of the steps that we went through for making this video. It will also show how to run a video project with total freedom, away from proprietary constraints. Finally, it underlines how amazing the Librem laptops are when used in a professional creative environment.

The post Making Videos With Absolute Freedom appeared first on Purism.

Volumio: How to Stream Local Music to Hi-Fi Systems

Volumio — 2026-08-05T00:03:47+00:00

A hard drive full of carefully collected albums should not feel like a relic from the CD-ripping era. Whether your collection lives on a NAS drive, a computer, or a USB disk, you can stream local music to hi-fi equipment with the same ease you expect from a modern streaming service – while keeping the master files, artwork, and listening choices in your hands.

The difference is not simply getting sound from storage to speakers. A well-built local streaming setup turns your personal library into a living part of your system: searchable from the listening chair, playable in high resolution, and available alongside the services you use every day.

Why local music still belongs in a modern hi-fi system

Streaming subscriptions are excellent for discovery, but a local library offers something different. It may contain out-of-print releases, live recordings, alternate masters, purchased downloads, or years of music organized with care. It also gives you consistency. The version of an album you choose is the version you hear, without catalog changes or shifting availability.

For many listeners, sound quality is another reason. Local files can be played in their original resolution, including CD-quality FLAC and high-resolution PCM or DSD files where your hardware supports them. That does not mean every high-resolution file will automatically sound better. The quality of the recording, master, DAC, amplifier, speakers, and room still matter more than a number on a file label. But local playback removes unnecessary compromises between your collection and your system.

There is also a practical advantage: your music remains available even when internet service is unreliable. The player only needs access to your home network or directly attached storage, depending on how you configure it.

What you need to stream local music to hi-fi

At its simplest, local streaming requires three things: a place where music files are stored, a network music player that can find and play them, and a connection to your hi-fi system.

Your storage can be a computer, a network-attached storage device, or a USB drive connected directly to the player. A NAS is often the best long-term choice for larger libraries because it stays on independently of your computer and can serve music to more than one listening zone. A computer is perfectly suitable for a smaller collection or a first setup, especially if it is already on when you listen.

The music player is the bridge between your library and your stereo. It connects to the network, scans your files into a browsable library, and sends audio to an integrated amplifier, external DAC, or active speakers. Some systems include digital and analog outputs, while others are designed as digital transports for listeners who already own a DAC they love.

A stable wired Ethernet connection is preferable when possible, particularly for large high-resolution libraries or a busy household network. Good Wi-Fi can work very well, but distance from the router, dense walls, and network congestion can affect reliability. If playback occasionally stops or albums take too long to appear, the network is usually the first place to investigate.

Choose files your system can read

FLAC is a sensible default for most local libraries. It is lossless, supports metadata and artwork, and is widely compatible. ALAC offers similar benefits for collections built around Apple software. WAV and AIFF can sound excellent but tend to consume more storage space, and WAV metadata support is less consistent across software.

MP3 and AAC remain useful for casual listening or older collections, though they are lossy formats. There is no need to replace a beloved collection overnight. Start by playing what you own, then use lossless files for new rips and downloads when sound quality and archiving matter to you.

Build a library that is satisfying to browse

The best player interface cannot rescue a poorly organized library. Before your first scan, spend time on filenames, album folders, artwork, and metadata. This work pays off every time you search for an artist, browse by genre, or select an album without reaching for a keyboard.

A simple folder structure is usually enough: Artist, then Album, then tracks. Keep multi-disc releases together in a clearly labeled album folder. Use consistent album-artist tags for compilations and box sets, or those releases may be scattered across multiple artist pages.

Metadata deserves particular attention. Artist, album artist, album title, track number, disc number, release year, genre, and embedded cover art are the fields that most directly improve daily browsing. Classical and jazz listeners may also want to tag composer, conductor, ensemble, soloist, and recording date. The right approach depends on how you actually look for music. A collection organized around composers needs different detail than one centered on performers and albums.

Artwork should be embedded in the files when possible. Folder images can work, but embedded artwork travels with the music if you later move files to another drive or server. Avoid enormous image files if your library scan becomes slow; a clean square image at a sensible resolution is more than enough for most control screens.

Connect the player to the rest of your system

The connection you choose depends on the role of your player. If you have an external DAC, use a digital output such as USB, coaxial, or optical, according to the inputs your DAC supports. USB can support very high sample rates and DSD on compatible equipment, while coaxial and optical can be excellent, straightforward choices within their format limits.

If your streamer has a high-quality built-in DAC and your amplifier accepts analog inputs, connect it with RCA or balanced XLR where available and appropriate. Balanced connections are not automatically superior in every system, but they can help reject noise over longer cable runs and suit components designed for balanced operation.

Keep the setup honest and simple. Expensive cables will not correct a weak network, messy metadata, or a poor speaker position. Put your attention first on reliable networking, sensible component matching, and a speaker setup that lets the music breathe.

Avoid unwanted resampling and volume mistakes

For the most direct playback path, configure your player to preserve the source file’s native sample rate when your DAC supports it. This is often called bit-perfect playback. It ensures the player does not resample every track to a fixed rate before output.

That said, bit-perfect playback is not a requirement for musical enjoyment. Some systems intentionally use DSP, room correction, upsampling, or digital volume control. These can be worthwhile features, especially if they solve a real issue in your room. The key is to understand where processing happens and avoid stacking multiple volume controls at low levels, which can reduce usable resolution or create awkward gain settings.

Make local files feel as convenient as streaming

Once the music is indexed, local playback should not require a technical ritual. You should be able to open one control interface, browse new additions, search an artist, queue an album, and move from your own files to a streaming service without changing devices or rebuilding playlists.

This is where a dedicated music-player ecosystem earns its place. Volumio brings local libraries, supported streaming services, internet radio, and connected playback hardware into one focused interface, so the music source does not dictate how you listen. For makers, the same approach can begin with a Raspberry Pi or PC-based player. For a finished system, a dedicated streamer can provide a more refined physical and electrical foundation.

Playlists are especially useful for closing the gap between ownership and discovery. Build one around a favorite label, a live set, a particular producer, or a mood that crosses formats. A local track can sit next to a streamed album and a radio discovery without turning your evening into an exercise in app switching.

Troubleshoot the issues that matter most

When local music does not appear, the cause is often basic: the player cannot see the shared folder, login credentials have changed, or the storage device is asleep. Confirm that the folder is shared on the network, that the player has permission to read it, and that both devices are on the same network.

If an album appears with missing artwork or tracks in the wrong order, inspect the tags before blaming the player. Track and disc numbers, album-artist fields, and embedded cover art solve a surprising number of library problems. After editing metadata, trigger a library rescan so the changes are reflected.

Dropouts point more often to network conditions than file quality. Try Ethernet, move the player away from sources of wireless interference, or reserve Wi-Fi for lower-demand locations. If you are playing from a USB drive, test another cable or power source before assuming the drive itself has failed.

A local library is not about rejecting streaming. It is about giving your own music the same care as the rest of your hi-fi system. Put on the album you know by heart, let it play without interruption, and make room for the next record waiting in your collection.

The post How to Stream Local Music to Hi-Fi Systems appeared first on Volumio.

Tails: Tails 7.10.1

Tails — 2026-08-05T00:00:00+00:00

This release is an emergency release to fix critical security vulnerabilities in the Linux kernel and the expat XML library.

Changes and updates

Update the Linux kernel to 6.12.100, which fixes CVE-2026-64560, a vulnerability that could allow Tor Browser in Tails to gain administrator privileges.

For example, if a malicious website that you visit is able to exploit CVE-2026-64560, they might take full control of your Tails and deanonymize you.

This attack is very unlikely but could be performed by a strong attacker, such as a government or a hacking firm. We are not aware of this attack being used in practice until now.
Update the expat XML library to 2.8.2, which fixes DSA-6404-1, a set of vulnerabilities that could allow different applications in Tails to gain administrator privileges.

For example, if an attacker tricks you into opening a malicious file in an application that uses expat, such as LibreOffice, Audacity, or Git, they might then use one of these vulnerabilities to take full control of your Tails and deanonymize you.

This attack is very unlikely but could be performed by a strong attacker, such as a government or a hacking firm. We are not aware of this attack being used in practice until now.
Compress automatic upgrades with zstd for a faster startup, as we already did for the USB image in Tails 7.0.
Make USB images and automatic upgrades 70 MB smaller by removing unused firmware.

For more details, read our changelog.

Get Tails 7.10.1

To upgrade your Tails USB stick and keep your Persistent Storage

Automatic upgrades are available from Tails 7.0 or later to 7.10.1.
If you cannot do an automatic upgrade or if Tails fails to start after an automatic upgrade, please try to do a manual upgrade.

To install Tails 7.10.1 on a new USB stick

Follow our installation instructions.

The Persistent Storage on the USB stick will be lost if you install instead of upgrading.

To download only

If you don't need installation or upgrade instructions, you can download Tails 7.10.1 directly:

Deepin: deepin 25.2.1 Update

xiaofei — 2026-08-04T03:11:51+00:00

Learn more about deepin on DistroWatch: https://distrowatch.com/table.php?distribution=deepin The deepin 25.2.1 update is here! This update brings numerous feature optimizations and bug fixes, focusing on file management & search, system upgrade reliability, general application compatibility, and system security. We welcome all deepin community members and open-source enthusiasts to install the latest release and share your feedback! Feel free to discuss and share your thoughts and experiences in the comments — thank you all! Key Updates Intelligent Search Is Now Available: File Manager and Global Search now support more natural ways to find local files. You can search with phrases such as ...Read more

Deepin: (中文) 重磅更新！小U同学「全局知识库」上线：你的本地文件，终于"活"起来了

xiaofei — 2026-08-04T02:04:41+00:00

Sorry, this entry is only available in 中文.

ARMBIAN: Github Highlights

Michael Robinson — 2026-08-04T01:34:40+00:00

This week&aposs work centers on a consolidated uwe5622 Wi-Fi/Bluetooth driver, CI and repository infrastructure changes, and board and toolchain enablement across multiple SoC families.

The uwe5622 driver has been relocated to a dedicated repository and unified across kernel versions. Initial commits address a use-after-free in mtty_probe(), resolve 157 -Wmissing-prototypes warnings, correct dev_addr const guards for kernels 5.17–6.18 under clang, and fix sdio_pub_int_init for the newer gpiod int_ap API on GCC 14. The build system now sources the driver from this repository, adds a GitHub Actions test workflow, and refactors the associated DVFS patch and kernel configuration.

CI and publishing pipelines received substantial attention. Nightly images have moved from the os to the ci release channel, with the download portal, router, and reporting scripts updated to match. The community build now publishes to its own repository and version series, dispatch inputs have been trimmed, and board/maintainer dropdowns are auto-generated for standard-support builds. Stall recovery gained a five-attempt budget with a >50% success gate, later raised back to ten attempts. On the repository side, repo-reprepro now skips missing .deb files rather than aborting and logs a single count of skipped packages.

Platform work spans several architectures. New boards include the Anbernic RG Vita Pro (RK3576) handheld and the Recomputer RK3576 devkit, while EasePi-A2/R2 mainline U-Boot advances to v2026.07. Toolchain fixes enable imx8ulp libbpf builds on GCC 15, fit the AM62P/AM62-LP R5 SPL into SRAM under GCC 13, and correct a sunxi-6.12 Bluetooth quirk for the pre-6.16 API. Additional user-visible changes include a new BTRFS_CHECKSUM build switch, F2FS enabled across all kernels via a central config hook, and parallelized patch rewriting scaled to nproc.

#Armbian #EmbeddedLinux #RK3576 #uwe5622 #CI

Changes

Add a BTRFS_CHECKSUM build switch for choosing the checksum algorithm. by @dlitz in armbian/build#10288
Add board: Anbernic RG Vita Pro (RK3576 gaming handheld). by @crackerjacques in armbian/build#10128
add parallel patching switches. by @EvilOlaf in armbian/documentation#945
auto-retry-stalled: 5-attempt budget, retry only when >50% of jobs succeed. by @igorpecovnik in armbian/ci#36
board: set HAS_VIDEO_OUTPUT at board level so the build-list inventory sees it. by @igorpecovnik in armbian/build#10309
Build firmware paths with a single bounded snprintf. by @iav in armbian/uwe5622#6
build-community: trim dispatch inputs to match nightly. by @igorpecovnik in armbian/ci#37
Build-Switches: document BTRFS_CHECKSUM. by @dlitz in armbian/documentation#946
ci: auto-generated board/maintainer dropdowns for standard-support builds. by @igorpecovnik in armbian/ci#40
ci: community publishes to armbian/community with its own version series. by @igorpecovnik in armbian/ci#38
ci: raise stall-recovery retry budget back to 10 attempts. by @igorpecovnik in armbian/ci#39
cix-p1: edge: update patches for 7.1.5, remove version pin. by @EvilOlaf in armbian/build#10297
cli-patch: generalize to-git push (PUSH_TO_GITHUB / PUSH_TO_REPO), for u-boot too. by @igorpecovnik in armbian/build#10193
docs: document the show-extensions build command. by @iav in armbian/documentation#944
Fix -Wmissing-prototypes warnings (157 → 0). by @iav in armbian/uwe5622#5
Fix dev_addr const guards for kernels 5.17-6.18 (clang). by @iav in armbian/uwe5622#3
Fix use-after-free in mtty_probe() error path. by @enromytase in armbian/uwe5622#4
fix(sc8280xp-vendor): rebase DP retrain patch onto moving radxa 7.0.11 branch. by @igorpecovnik in armbian/build#10305
gha: add test workflow based on armbian. by @EvilOlaf in armbian/uwe5622#7
hetzner: stop masking create_servers.py errors on failure. by @igorpecovnik in armbian/actions#34
imx8ulp: enable scoped kernel patches so the libbpf/gcc-15 fix applies. by @igorpecovnik in armbian/build#10312
imx8ulp: fix libbpf const-discard so resolve_btfids builds on gcc 15. by @igorpecovnik in armbian/build#10310
json: fix duplicate and over-length menu IDs. by @igorpecovnik in armbian/configng#957
k3: fit am62p/am62-lp R5 SPL into SRAM (GCC 13 + per-SoC size handling), fix tispl rename & u-boot artifact hashing. by @igorpecovnik in armbian/build#10237
kernel: enable F2FS on all kernels (central config hook). by @igorpecovnik in armbian/build#10178
map: key nightly/ prefix on download_repository "ci" (nightly moved os→ci). by @igorpecovnik in armbian/armbian-router#42
recomputer-rk3576-devkit: edge/mainline enablement. by @rpardini in armbian/build#10235
Refactor DVFS patch and clean up uwe5622 driver kernel configuration. by @EvilOlaf in armbian/build#10316
repo-reprepro: log a count of skipped debs, not one line each. by @igorpecovnik in armbian/build#10303
repo-reprepro: skip debs missing on disk instead of aborting the whole repo. by @igorpecovnik in armbian/build#10301
reporting: download-images report (versions provided + anomalies) to job summary. by @igorpecovnik in armbian/armbian.github.io#371
rewrite patches: speed up the process up to nproc. by @EvilOlaf in armbian/build#10163
rockchip64-6.18: overlays: rewrite README.md. by @EvilOlaf in armbian/build#10295
rockchip64: add NanoPi NEO3 onboard fan (CON4) pwm-fan overlay. by @tenox7 in armbian/build#10291
rootfs: bump force-rebuild counter to 007. by @igorpecovnik in armbian/build#10311
runner-clean: keep qemu-user-static current (fixes stale-qemu cross-arch failures). by @igorpecovnik in armbian/actions#33
scripts: source nightly images from armbian/ci releases (moved from os). by @igorpecovnik in armbian/armbian.github.io#370
software/jellyfin - Add host mounts for music, books. by @jjg in armbian/configng#955
sun60iw2: enable CONFIG_TUN as module for VPN support (Tailscale/WireGuard). by @diegodsgarcia in armbian/build#10302
sunxi-6.12: fix bluetooth park-link quirk to use pre-6.16 API (test_bit). by @igorpecovnik in armbian/build#10299
uboot: bump EasePi-A2/R2 mainline U-Boot to v2026.07 and add resolute release support. by @ifroncy01 in armbian/build#10274
update readme. by @EvilOlaf in armbian/uwe5622#2
uwe5622: bump driver commit. by @EvilOlaf in armbian/build#10317
uwe5622: source the driver from armbian/uwe5622 (incl. the >=7.1 gpiod fix). by @igorpecovnik in armbian/build#10300
uwe5622: switch to unified driver in dedicated repo. by @EvilOlaf in armbian/build#10113
wcn_boot: fix sdio_pub_int_init for the >=7.1 gpiod int_ap (GCC14 -Wint-conversion). by @igorpecovnik in armbian/uwe5622#1

Volumio: Best Audio OS for Raspberry Pi for Hi-Fi Listening

Volumio — 2026-08-04T00:03:57+00:00

A Raspberry Pi behind a good integrated amplifier can become a wonderfully focused music source, or a tiny computer that constantly asks for attention. The difference is the software. Choosing the best audio OS for Raspberry Pi is less about chasing technical jargon and more about creating a player that makes your library, favorite streaming service, and listening room feel connected.

For a hi-fi system, an audio OS should disappear once the music starts. It should let you browse an album from your own collection, queue a new release, select the right output, and listen without negotiating with a desktop interface, a keyboard, or several disconnected apps. That is the standard worth using when you compare your options.

What Makes the Best Audio OS for Raspberry Pi?

A general-purpose operating system can play music, but it is not built around listening. It has background tasks, desktop windows, updates meant for office work, and endless ways to interrupt a session. An audio-focused operating system takes a different approach: it turns the Pi into a dedicated network player controlled from a phone, tablet, or browser.

The best choice should handle the sources you actually use. For some listeners, that means a carefully tagged FLAC library on a network drive. For others, it means TIDAL, Qobuz, Spotify, internet radio, or a combination of all four. A strong audio OS brings those sources into one interface, so choosing music does not begin with deciding which app has it.

Sound quality matters, but it deserves a clear-eyed view. An operating system cannot repair a poor DAC, noisy power, or a badly matched output. It can, however, provide a stable playback path, support high-resolution formats where your equipment benefits from them, and give you proper control over USB DACs and I2S audio boards. The goal is reliable, bit-perfect playback when appropriate, not a collection of settings that look impressive but add confusion.

Ease of use is equally important. If other people in your household cannot find an album, start radio, or change volume without calling you, the system is not finished. A Raspberry Pi music player should feel like part of the hi-fi rack, not like a weekend project left open on a workbench.

Start With Your Listening System, Not the Pi

Before installing anything, decide how the Raspberry Pi will connect to your system. A USB DAC is the most flexible route and works well with a wide range of existing DACs and integrated amplifiers. An I2S DAC board, often called a HAT, can make for a compact all-in-one build with fewer cables. If your amplifier or DAC accepts a digital signal directly, a dedicated digital output board may be the better fit.

This decision shapes what you need from the OS. It must recognize your chosen output and make switching sample rates predictable. It should also offer clear volume behavior. If your DAC or amplifier has its own high-quality analog volume control, many listeners prefer to run the player at a fixed output level. If you need software volume, use it deliberately and understand where it sits in the signal path.

Your network deserves the same attention. Wired Ethernet is usually the simplest answer for a stationary hi-fi setup, particularly with high-resolution files stored on a network drive. Wi-Fi can work very well when the signal is strong, but it adds another variable when diagnosing dropouts. A good audio OS should make both options straightforward rather than requiring command-line network setup.

Why Volumio OS Fits Most Hi-Fi Builds

For most listeners building a Raspberry Pi network player, Volumio OS is the strongest choice because it treats music playback as the whole purpose of the device. It combines local libraries, supported streaming services, web radio, and connected audio hardware in a single music-first environment. The interface is accessible enough for a first build while offering the output configuration and playback controls experienced hobbyists expect.

That balance matters. A bare-bones player can be satisfying if you only send audio from one app, but it becomes limiting when your collection grows or your listening habits change. A full desktop distribution offers flexibility, yet that flexibility often means more maintenance, more processes running in the background, and less focus at the rack. A dedicated player environment occupies the useful middle ground: purpose-built, approachable, and capable of growing with the system.

It is especially well suited to listeners with mixed sources. You may own years of ripped CDs, keep a high-resolution download library, and use a streaming subscription to explore new music. Those should not feel like separate systems. A unified library and browsing experience lets the listening session lead, whether you begin with a familiar Miles Davis record or follow a recommendation into something new.

There is also a practical benefit for builders. A focused audio OS removes much of the work that normally comes after installing a general-purpose computer platform: configuring the player, setting up a control interface, connecting storage, and making audio hardware behave consistently. You still get the pleasure of choosing the Pi, DAC, case, cables, and power arrangement. You simply spend less time maintaining software and more time listening.

When Another Type of Audio OS May Make Sense

The best answer does depend on the job. If you want the Raspberry Pi only as a lightweight endpoint for a single protocol, a minimal endpoint-focused system may be enough. It can be a sensible choice for a secondary room where another device handles library management and service integration.

A desktop-based setup may also suit someone who wants the Pi to run unrelated software alongside music playback. That approach is more flexible, but it asks you to accept a computer-like experience. Updates, notifications, and manual configuration can become part of ownership.

For a primary hi-fi system, those compromises are rarely attractive. Most owners want a player that turns on, reconnects to the network, remembers its library, and remains easy to control months after the original build. The more central the Pi is to your daily listening, the more value there is in choosing an OS designed specifically for that role.

Build Details That Affect the Result More Than You Think

Once you have selected the software, avoid treating every accessory as equally important. Start with a current Raspberry Pi model that has enough processing headroom for your library and preferred features, a quality power supply, dependable storage, and stable networking. Then choose the output hardware that suits the rest of the system.

A clean, appropriately rated power supply can be worthwhile, especially in a revealing system, but it is not a substitute for sound setup fundamentals. Put the Pi in a case that protects the board and allows ventilation. Use a short, dependable USB cable if connecting to a DAC. If you are using an I2S board, confirm that the board and selected output driver match before judging sound quality.

Library organization pays off every time you browse. Consistent artist, album, composer, genre, and artwork metadata makes a large collection inviting instead of frustrating. For classical music, composer and work tags are particularly valuable. For jazz and live recordings, accurate album-artist tags prevent one release from being scattered across multiple artist pages.

Do not rush past the first listening session. Start with a few recordings you know intimately: a vocal track for presence, an acoustic recording for space, a dense arrangement for separation, and a familiar low-frequency passage for control. Listen at normal levels. The aim is not to hunt for differences between settings, but to verify that the system feels stable, natural, and easy to enjoy.

A Better Test Than Comparing Feature Lists

Feature lists can make every audio OS look similar. The better test is what happens on an ordinary Tuesday night. Can you find the album you want in seconds? Can you move from your own library to a streaming discovery without changing devices? Does the player remain responsive when a family member uses it? Can you return to the system after an update without relearning it?

Those small moments determine whether a Raspberry Pi becomes a cherished part of the system or a clever experiment that eventually gets unplugged. Choose the platform that keeps the path from curiosity to music short, then give yourself an evening with a favorite record and no reason to touch a computer.

The post Best Audio OS for Raspberry Pi for Hi-Fi Listening appeared first on Volumio.

Xanadu developers: Protege tu Homelab: SSL Automático con Nginx Proxy Manager y Cloudflare

Jesus Palencia — 2026-08-03T23:29:14+00:00

ZEVENET: Why Vendor Dependency Is Becoming a Strategic Infrastructure Risk

Isabel Perez — 2026-08-03T10:56:17+00:00

What we are seeing across enterprise ADC projects, and why more infrastructure teams are re-evaluating long-term vendor dependency.

For years, infrastructure decisions were assessed through a familiar set of criteria: performance, availability, security, compatibility and cost.

Those factors still matter. But conversations around critical infrastructure are becoming broader.

In discussions with customers, partners and infrastructure teams, another question is appearing more frequently:

How much operational and strategic dependency are we creating when a critical part of our infrastructure relies on a single vendor?

Vendor dependency becomes a strategic infrastructure risk when relying on a provider starts to limit an organization’s ability to control costs, change deployment models, evolve its architecture or respond to new operational requirements. The risk lies not in the relationship itself, but in the loss of practical alternatives.

This question is particularly relevant for Application Delivery Controllers. Sitting directly in the path of application traffic, ADCs have evolved far beyond load balancing. Today, they combine traffic management, high availability, application security and policy enforcement, making them one of the most critical layers of enterprise infrastructure.

As a result, choosing an ADC influences far more than technical performance. It can affect how easily infrastructure evolves, how predictable future costs remain, how quickly teams respond to change and, ultimately, how much control an organization retains over its own architecture.

Vendor dependency is not inherently a problem. Every organization relies on strategic technology providers. The challenge begins when that dependency becomes difficult to measure, expensive to change or no longer aligns with the organization’s long-term infrastructure strategy.

Five signs vendor dependency is becoming an infrastructure risk

Organizations rarely review an ADC platform because of a single failure.

More often, the conversation begins as infrastructure evolves, operational demands increase or commercial conditions change. Over time, a series of small decisions can lead teams to question whether the platform they selected years ago still supports the way they want to operate today.

Across enterprise ADC projects, these are the five signals we encounter most often.

These are qualitative patterns from projects and conversations with infrastructure teams and partners, not the results of a formal survey — but they are the signals that come up most consistently when organizations reassess their ADC strategy.

1. ADC licensing becomes harder to predict

Licensing is often treated as a commercial issue. In reality, it can have a significant impact on infrastructure strategy.

A platform may initially meet every technical and financial requirement, but as environments grow, the commercial model can become increasingly difficult to forecast.

This may happen when capabilities are divided across multiple editions, additional modules are required for security or management, support levels change, or infrastructure growth introduces new licensing requirements.

The question is not simply whether the platform is expensive.

It is whether the organization can confidently predict the cost of operating and expanding it over the coming years.

For CIOs, that affects budgeting and long-term planning. For infrastructure teams, it can influence architectural decisions by discouraging new deployments, delaying expansion or limiting the adoption of capabilities that are technically available but commercially difficult to justify.

It also makes the total cost of ownership harder to assess. Licensing fees may be only one part of the equation. Additional management products, security modules, specialist skills, support contracts and migration costs can all affect the long-term economics of the platform.

When licensing begins to shape infrastructure decisions more than technical requirements, vendor dependency becomes a strategic concern rather than a procurement issue.

2. Deployment flexibility across hybrid infrastructure starts to decline

Enterprise infrastructure no longer follows a single deployment model.

Many organizations now operate across a combination of on-premises systems, virtualized environments, private cloud, public cloud and geographically distributed data centers.

While many ADC platforms support these environments, support alone does not guarantee operational consistency.

The more important questions are:

Can the same operating model be maintained across different environments?
Can configurations move without redesigning the architecture?
Does the organization remain free to choose where workloads run?
Will future cloud or virtualization decisions force a change in ADC strategy?

Configuration portability is particularly important. An ADC configuration may include virtual services, health checks, persistence policies, traffic-management rules, TLS certificates, WAF policies and automation scripts. If those elements depend heavily on proprietary formats or interfaces, moving to another environment or platform can require more than deploying a replacement appliance.

Infrastructure teams increasingly value platforms that adapt to different deployment models instead of encouraging a single infrastructure path.

This matters because an ADC is rarely deployed for only a few years. The environment around it will almost certainly evolve, and today’s platform decision should not unnecessarily restrict tomorrow’s architecture.

3. Innovation begins to follow the vendor’s roadmap, not the organization’s

Every technology vendor has its own product roadmap.

The challenge arises when an organization’s priorities begin to diverge from it.

Perhaps the business needs support for a new deployment model, deeper automation, a different licensing approach or faster access to technical expertise. None of these requests may be strategically important to the vendor, even though they are important to the customer.

This is a natural consequence of large product portfolios serving thousands of organizations with different priorities.

The question is not whether the vendor continues to innovate.

The question is whether that innovation is aligned with the direction in which the customer’s infrastructure is actually moving.

When that alignment weakens, organizations can find themselves delaying projects, adapting their own plans or accepting compromises simply because changing direction has become increasingly difficult.

4. Operational complexity continues to grow

Infrastructure complexity rarely appears overnight.

It accumulates over time.

A platform that was straightforward to manage a few years ago can become increasingly difficult to operate as organizations add new applications, expand into different environments, strengthen security controls or introduce additional management tools.

For technical teams, the consequences are practical rather than theoretical.

Routine changes may require multiple interfaces. Troubleshooting can involve different products or support channels. Knowledge becomes concentrated in a small number of specialists, making day-to-day operations harder to maintain and scale.

Automation can become another source of dependency. APIs, configuration models and orchestration workflows may be closely tied to a particular platform. The more operational processes depend on proprietary implementations, the higher the switching costs become.

This affects more than operational efficiency. It can increase configuration risk, extend troubleshooting times and make even simple changes more difficult than they need to be.

For many infrastructure teams, simplicity is no longer a “nice to have”. It has become an operational requirement. A platform that is easier to understand, monitor and manage allows teams to spend less time maintaining infrastructure and more time improving it.

5. Business resilience depends on more than high availability

High availability has always been one of the primary reasons for deploying an ADC.

But resilience extends beyond keeping applications online during a technical failure. It also includes the organization’s ability to adapt when infrastructure, business priorities or commercial conditions change.

A highly available platform can still create strategic constraints if workloads are difficult to move, costs are unpredictable, expertise is hard to access or the architecture cannot evolve without significant redesign.

True resilience is therefore not simply the ability to withstand failure. It is the ability to continue operating and evolving without being unnecessarily constrained by decisions made years earlier.

When an infrastructure project triggers an ADC strategy review

One of the misconceptions surrounding ADC migrations is that they happen because an existing platform has failed.

In reality, that is rarely what we see.

More often, an unrelated infrastructure project creates an opportunity to revisit decisions that may have remained unchanged for years:

A hardware refresh.
A cloud migration.
A licensing renewal.
An infrastructure modernization initiative.

A good example is the migration carried out by Pablo de Olavide University.

What initially began as a hardware renewal became a broader assessment of the organization’s ADC strategy. Rather than simply replacing appliances, the team evaluated operational complexity, long-term costs, support and whether the existing platform still aligned with its current infrastructure objectives.

The result was a migration to SKUDONET.

Not because the previous platform had stopped working.

But because the organization concluded that a different operational model was better suited to where its infrastructure was heading.

It is a pattern we are seeing more frequently across enterprise ADC projects.

Organizations rarely migrate because yesterday’s decision was wrong. They migrate because today’s requirements are different from those that shaped the original decision.

Questions worth asking before the next ADC decision

Reviewing an ADC platform does not necessarily mean planning a migration.

Sometimes the conclusion will be that the current platform remains the right choice.

The value lies in asking whether that choice still aligns with the organization’s future direction.

A structured review should consider five areas.

Commercial predictability

Can we predict the cost of operating and scaling the platform over the next three to five years?
Are core capabilities included, or do they depend on additional products, modules or licenses?
How could future changes to licensing or support affect the architecture?

Deployment and configuration portability

Can we deploy consistently across physical, virtual, cloud and hybrid environments?
Can configurations, policies and operational processes move between environments?
Are we dependent on proprietary formats or platform-specific tooling?

Operational maintainability

How easy is it for our teams to monitor, troubleshoot and evolve the platform?
Is operational knowledge distributed across the team or concentrated in a few specialists?
Can the platform integrate with our existing automation and observability workflows?

Roadmap alignment

Does the current ADC still support our infrastructure roadmap?
Is the vendor’s product direction aligned with our automation, security and deployment requirements?
Can we access technical expertise quickly when it matters most?

Exit readiness

Do we understand the technical and operational cost of changing platforms?
Can configurations and policies be documented or exported in a usable format?
Is there a realistic migration path if the platform no longer meets our requirements?
Would we make the same decision if we were selecting an ADC today?

These questions are not intended to create dissatisfaction with an existing vendor.

They are intended to determine whether the current platform continues to create more value than constraint.

An exit strategy does not mean an organization expects to leave its provider. It means the organization understands what would be required if circumstances changed. That knowledge makes vendor dependency measurable rather than assumed.

Looking beyond the next renewal

Organizations do not need to eliminate vendor dependency.

In practice, every enterprise depends on strategic technology partners.

The goal is to understand where that dependency exists, whether it remains acceptable and how it might affect future infrastructure decisions.

That means looking beyond current availability and performance. Organizations should also consider switching costs, configuration portability, interoperability, roadmap alignment and whether a practical exit strategy exists.

The EU’s NIS2 Directive is a useful external reference point here: recital 90 calls for coordinated supply chain risk assessments to identify critical dependencies and single points of failure, the same concern this article addresses at the ADC layer.

The best time to ask these questions is not when an urgent migration becomes unavoidable. It is during the routine planning cycles in which architecture, costs and operational requirements are already being reviewed.

By treating vendor dependency as a strategic consideration rather than simply a procurement issue, organizations give themselves more options for the future. That optionality is one of the most valuable forms of infrastructure resilience.

Frequently Asked Questions About Vendor Dependency

What is vendor dependency?

Vendor dependency refers to the degree to which an organization’s operations, infrastructure or business strategy rely on a specific technology provider.

Dependency itself is not necessarily a risk. It becomes a concern when it limits flexibility, makes costs difficult to predict, restricts architectural decisions or makes it difficult for the organization to adapt as infrastructure and business requirements evolve.

What is the difference between vendor dependency and vendor lock-in?

Vendor dependency is a natural outcome of working with strategic technology providers.

Vendor lock-in occurs when changing provider becomes technically, operationally or commercially difficult. This may be caused by proprietary technologies, non-portable configurations, specialist knowledge requirements, contractual conditions or high migration costs.

All organizations have some level of vendor dependency, but not all experience vendor lock-in.

When does vendor dependency become a strategic infrastructure risk?

Vendor dependency becomes a strategic infrastructure risk when it starts to influence decisions that should be based on technical or business requirements.

Warning signs include unpredictable licensing, declining deployment flexibility, increasing operational complexity, misalignment with the vendor’s roadmap and the absence of a realistic exit strategy.

How can organizations reduce vendor dependency in an ADC strategy?

Organizations can reduce vendor dependency by prioritizing deployment flexibility, configuration portability, documented APIs, interoperability and predictable licensing.

They should also understand switching costs, document operational processes and periodically test whether the platform continues to support their infrastructure roadmap.

Using multiple vendors is not the only option. The objective is to preserve practical alternatives and avoid unnecessary constraints.

Continue the conversation

Every ADC evaluation starts for a different reason, but the objective is the same: ensuring today’s infrastructure decisions continue to support tomorrow’s requirements.

If your team is reviewing its ADC strategy—or simply wants a second technical perspective—we would be happy to share our experience and discuss the architectural considerations that typically emerge during these evaluations.

Talk to our engineering team

Volumio: How to Build a Raspberry Pi Music Streamer

Volumio — 2026-08-03T09:03:10+00:00

A Raspberry Pi can become far more than a small computer tucked behind a television. Connected thoughtfully to your hi-fi, it can be a focused network music player: one place to browse a personal library, play music from streaming services, and send a clean digital signal to the rest of your system. If you are searching for “how to build raspberry pi music streamer,” the good news is that the project is approachable. The more important news is that a few decisions made before you start will have a real effect on sound quality, everyday convenience, and how long the player remains useful.

How to Build a Raspberry Pi Music Streamer That Fits Your System

Start with the role the streamer will play. A Raspberry Pi music streamer does not need to replace every component in your system. It may feed an existing DAC, connect directly to an integrated amplifier with digital inputs, or serve as an all-in-one digital source when paired with a DAC expansion board.

That decision determines the connection path. If you already own a DAC you enjoy, USB output is often the simplest route. It keeps the Raspberry Pi separate from digital-to-analog conversion and gives you flexibility to change DACs later. If your amplifier or DAC accepts S/PDIF, an add-on board can provide coaxial or optical output. If you want the smallest possible system, a DAC HAT can sit directly on the Pi’s GPIO header and provide analog outputs.

There is no universally superior option. A good USB DAC may be the right match for one system, while a quality DAC HAT can be wonderfully compact and satisfying in another. Let the inputs on the equipment you already own guide the build instead of buying parts simply because they are popular.

Choose the core hardware

For most listeners, a Raspberry Pi 4 provides more than enough performance for music playback. It has dependable networking, USB ports for a DAC or storage drive, and broad support across audio software. A Raspberry Pi 5 offers more processing headroom, but a music streamer rarely needs its extra power. It can also run warmer, so it is not automatically the better listening-room choice.

A practical parts list includes:

A Raspberry Pi 4 or Raspberry Pi 5, plus its official or high-quality power supply
A microSD card from a reliable manufacturer, ideally 16 GB or larger
A case that leaves room for your selected output board, if using one
An Ethernet cable or a stable Wi-Fi connection
A USB DAC, digital-output HAT, or DAC HAT suited to your system
A phone, tablet, or computer for initial setup and everyday control

If your music library is stored locally, you may also need a USB hard drive, SSD, or network-attached storage. An SSD is quiet, fast, and generally a better fit for a listening room than a spinning drive, though either can work well.

Do not treat the power supply as an afterthought. The Pi itself is sensitive to insufficient power, and voltage instability can cause dropouts, storage corruption, or inconsistent behavior. Use a supply designed for the model you choose. Once the system is working, you can decide whether an upgraded low-noise power supply makes sense in the context of the whole system.

Build the Signal Path Before Installing Software

Assemble the hardware with the Raspberry Pi powered off. Install a DAC HAT or digital-output HAT carefully, ensuring its GPIO pins are aligned before applying pressure. Fit the Pi into its case, connect Ethernet if possible, then attach the chosen audio output to your DAC, amplifier, or active speakers.

Wired Ethernet is the sensible default for a fixed hi-fi installation. It avoids the occasional uncertainty of Wi-Fi and is particularly worthwhile with high-resolution files or busy home networks. Wi-Fi can still be an excellent choice when the router is nearby and running a cable would compromise the room. The best network connection is the one that stays stable while you listen.

For USB audio, connect the DAC directly to the Pi at first. Avoid adding USB hubs until the basic system is confirmed to work. For a coaxial or optical HAT, use a properly terminated cable and select the appropriate input on your downstream component. With an analog DAC HAT, connect its RCA outputs to a line-level input, never a phono input.

Keep volume control intentional. If your integrated amplifier or preamp is the best volume control in the system, set the streamer to fixed output where appropriate and control level downstream. If you are connecting directly to active speakers or a power amplifier, use the streamer’s volume control carefully and begin playback at a low level.

Install a Music-Focused Operating System

A general desktop operating system can play music, but it adds complexity you do not need in a dedicated player. A purpose-built audio operating system starts directly into a music interface, manages audio devices, and makes playback control available from a browser or companion app.

Write the chosen operating-system image to the microSD card using an imaging tool on your computer. Insert the card into the Pi, connect the network and audio hardware, then switch on the power. Give the system a few minutes for its first startup.

From a phone, tablet, or computer on the same network, open the player’s setup interface. You will typically select the active output, set network preferences, name the device, and configure your library. In Volumio, this process is designed around the listening experience rather than command-line administration, so a DIY player can feel at home beside a serious hi-fi component.

If you are using a DAC HAT or digital-output HAT, enable its specific driver in the audio settings. This step matters. The Pi may otherwise default to an output you are not using, or fail to recognize the board correctly. With a USB DAC, select it from the list of detected audio devices and confirm the supported sample rates.

Add local music and streaming services

For local files, point the streamer to a shared folder on a computer or network storage device, or connect a USB drive directly to the Pi. Organize music with clear album folders and accurate metadata before scanning. A beautiful player interface can only work with the information in your files, so clean artist names, album titles, artwork, and track numbers pay off every time you browse.

Then connect the services you use. Depending on your subscriptions and the software features available to you, this may include high-resolution streaming, internet radio, and other music sources. The goal is not to collect every possible service. It is to make the music you return to easy to find, whether it lives on a drive in your home or in a streaming catalog.

Take a moment to set library scan behavior, favorites, and playback queue preferences. These small choices turn a project into an appliance. When guests can find an album, when a late-night listening session begins without troubleshooting, and when your collection sits alongside the music you stream, the system is doing its job.

Set Up for Better Listening, Not Just Successful Playback

Once music plays, resist the urge to change ten settings at once. Begin with a familiar recording and verify the basics: left and right channels are correct, the output sample rate is as expected, and there are no clicks, dropouts, or sudden volume changes.

If playback is unreliable, work through the simplest causes first. Confirm that the power supply is sufficient, test Ethernet instead of Wi-Fi, try another USB cable, and make sure the DAC is selected as the active output. A large library may also take time to index, especially over a network share. These are usually setup issues, not signs that the Pi lacks the ability to be an excellent source.

Avoid unnecessary digital processing if your priority is faithful playback. Upsampling, equalization, and software volume control can all be useful in the right system, but they are choices rather than mandatory upgrades. Room correction or EQ may improve a difficult room dramatically. In a well-balanced system, a direct signal path may be preferable. Listen, compare, and keep the settings that serve your music.

A separate linear power supply, premium cables, and elaborate cases can be rewarding refinements, but they should come after reliability, correct configuration, and a sound output stage that matches your system. Put the budget where it makes the largest difference for your setup, whether that is a better DAC, speaker placement, room treatment, or simply more music.

Give the Project a Place in Your Listening Life

A Raspberry Pi streamer is especially compelling because it can grow with you. Start with USB into the DAC you already own. Add network storage when the library expands. Move to a different output board if your system changes. The software interface, playlists, and habits you build can remain at the center.

The best DIY streamer is not the one with the longest parts list. It is the one that disappears when the first notes begin, leaving your collection, your favorite services, and the pleasure of listening in one place.

The post How to Build a Raspberry Pi Music Streamer appeared first on Volumio.

SparkyLinux: Sparky news 2026/07

pavroo — 2026-08-01T17:25:15+00:00

The 7th monthly Sparky project and donate report of the 2026: – Linux kernel updated up to 7.1.5, 6.18.41-LTS, 6.12.100-LTS – added to our repos: Fooyin audio player Many thanks to all of you for supporting our open-source projects. Your donations help keeping them and us alive. Don’t forget to send a small tip in August too, please. * Keep in mind that some amounts coming to us…

Source

Purism PureOS: PureOS Development Report: June 2026

Purism — 2026-07-31T22:48:51+00:00

Thanks for joining us again! In our May update, we mentioned that we're bringing in updated dependencies as part of the goal to ship the latest Phosh desktop environment in PureOS Dawn.

The post PureOS Development Report: June 2026 appeared first on Purism.

GreenboneOS: CIS Benchmarks for Microsoft Environments: Greenbone’s Got You Covered!

Greenbone AG — 2026-07-31T12:03:42+00:00

Microsoft technologies are foundational to enterprise IT globally, providing the backbone for operation-critical databases, identity services, core server workloads, and daily productivity applications at many organizations. Greenbone is happy to announce new compliance scans aligned with four CIS Benchmarks for Microsoft environments. CIS Benchmarks provide prescriptive guidance for establishing secure configurations and complement essential security […]

Deepin: (中文) 从XDG标准到全球共建：如意玲珑迎来首个海外开源贡献

xiaofei — 2026-07-31T10:13:32+00:00

Sorry, this entry is only available in 中文.

Deepin: deepin-skills Officially Open-Sourced: Four Core Skills for deepin Developers

xiaofei — 2026-07-31T02:55:08+00:00

SUMMARY The deepin community has officially open-sourced deepin-skills, an AI-oriented development resource library for deepin 25. It includes four core skills: DTK application development, DDE Shell extension development, DDE Control Center plugin development, and DDE tray plugin development. This toolkit integrates official documentation, specifications and test cases. Compatible with AI programming Agents, it enables developers to acquire targeted technical guidance through natural language prompts and simplifies native desktop development within the deepin ecosystem. What is open-sourced deepin-skills project? It is a curated repository of developer skill sets built for native application and desktop plugin development on deepin. Whether you are new to ...Read more

Deepin: deepin社区2026上半年AI辅助开发产品大盘点：社区创造力大爆发！

xiaofei — 2026-07-31T02:40:29+00:00

Sorry, this entry is only available in 中文.

GreenboneOS: Patch Priority: An Emerging Tide of Linux Vulnerabilities Put Users in Hot Water

Joseph Lee — 2026-07-30T12:08:53+00:00

Several concerning vulnerabilities affecting Linux have emerged in recent months. The vulnerabilities include CISA Known Exploited Vulnerabilities (KEV) entries for CVE-2026-31431 (aka Copy Fail) [1], and an older flaw, CVE-2022-0492 [2]. However, a wave of concerning new vulnerabilities are associated with publicly available exploits or proof-of-concept (PoC) code. Collectively, the flaws represent local privilege escalation, […]

Univention Corporate Server: Introducing the Univention Integration Catalog: One Home for Every Integration

Vanessa Knoop — 2026-07-30T08:35:17+00:00

If you know Univention, you know the App Center. For years, it has been the go-to place for selecting and installing applications on Nubus for virtual machines (UCS). It has served its purpose well and that is exactly the point: our integration ecosystem has long outgrown installable apps.

Identity connectors, groupware integrations, ISV applications via the ID Broker, packaged integrations for cloud-native environments running Univention Nubus, the list is long. And it kept growing, while the individual scenarios remained scattered across different web pages, documentation and forum howtos. Administrators had to hunt for what they needed; partners struggled to make their solutions visible.

That changes now. The new Integration Catalog brings everything together in one place.

Everything in One Place – Searchable and Filterable

The Integration Catalog is the single entry point for every type of integration with Univention Nubus: App Center applications, identity and groupware connectors, ID Broker connections for the education sector, openDesk components – all in one searchable overview.

What works with our products? How do I get started? The catalog answers these questions directly – with filters by integration type, functionality and compatible product.

The Next Evolution of the App Center

The Integration Catalog does not replace the App Center, it builds on it. While the Univention App Center focuses on apps that are installed directly on Nubus for virtual machines (UCS), the catalog opens up the view to the entire integration ecosystem around Nubus. The familiar, curated experience stays the same.

Once the catalog goes live, it becomes the new central entry point and replaces the previous App Center catalog on our website.

And Sometimes No Software Is Needed At All

One insight the catalog makes properly visible for the first time: many applications work with Nubus without any additional software. Nubus is built on open standards, LDAP, SAML, OpenID Connect, and often a simple configuration is all it takes.

Take GitLab as an example: a community howto walks you through connecting a self-hosted GitLab to Nubus via LDAP and OIDC – without a single additional package. The catalog now showcases these documentation-based integrations on equal footing with installable apps and packaged integrations.

Open, Diverse and Always Up to Date

Diversity and flexibility: The catalog reflects the true breadth of the ecosystem – covering integrations for on-premises environments with UCS, cloud-native deployments with Nubus on Kubernetes, and solutions for education and the public sector.
Open and community-driven: All catalog entries are maintained as simple YAML files in a public GitHub repository. Partners, ISVs and community members can contribute new entries or update existing ones via pull request at any time.
Always up to date: The website syncs automatically with the repository. The catalog always reflects the latest state of the ecosystem – not a one-off snapshot, but a living picture of what is available.

What Does This Mean In Practice?

For decision-makers: See at a glance how many applications already connect to Nubus – and how low the barrier is for the next one.
For administrators: Find, evaluate and adopt integrations across schools, municipalities, enterprises and cloud-native environments faster with technical details such as protocols, supported deployments and direct links to documentation for every entry.
For partners and ISVs: Greater visibility for your integration with your own entry, logo and links, right where customers start their search.
For the ecosystem as a whole: More integrations, easier adoption, greater transparency, a healthier ecosystem around Nubus.

Explore It Now

The Integration Catalog is live at https://www.univention.com/products/integration-catalog/. More than 90 integrations are already listed – and the number keeps growing.

Take a look. And if you build integrations for our products, get in touch or open a pull request. We look forward to seeing your solution in the catalog.

Der Beitrag Introducing the Univention Integration Catalog: One Home for Every Integration erschien zuerst auf Univention.

ARMBIAN: Armbian Newsletter July 2026

Michael Robinson — 2026-07-29T15:29:43+00:00

Welcome to the latest Armbian Newsletter: your source for the latest developments, community highlights, and behind-the-scenes updates from the world of open-source ARM and RISC-V computing.

The upcoming Armbian release 26.08 will be based on Linux 6.18 LTS, giving users the benefits of a long-term support kernel with improved hardware compatibility, security updates, and ongoing upstream maintenance. This provides a solid foundation for future development while keeping systems stable and reliable.

Join us in making open source better! Every donation helps Armbian improve security, performance, and reliability so everyone can enjoy a solid foundation for their devices.

Github Highlights

This week’s work centers on new board enablement and platform maintenance, kernel and U-Boot refresh across Rockchip and Sunxi, and CI/build infrastructure improvements. Board support expanded with the addition of Sovol Zero, SV08, and SV08 Max on the H616 platform, alongside mainline and edge enablement for the

Beat the heat

Rising summer ambient temperatures erode the thermal headroom SBCs rely on, causing silent throttling and instability. Here’s why high-density SoCs like the RK3588 are most at risk, and how to pick the right cooling strategy to stay stable.

The factory behind Armbian

When you download an Armbian image, flash it to your SD card or SSD, and boot your board, a huge amount of automation has already happened behind the scenes. That invisible engine is what you can see at https://actions.armbian.com. Think of it as the mission control center

ARMBIAN: The factory behind Armbian

Igor Pecovnik — 2026-07-29T15:16:29+00:00

When you download an Armbian image, flash it to your SD card or SSD, and boot your board, a huge amount of automation has already happened behind the scenes.
That invisible engine is what you can see at https://actions.armbian.com.

Think of it as the mission control center of Armbian’s infrastructure.

It doesn’t look flashy, but it represents one of the most important parts of the project: the system that builds, tests, validates, and maintains Armbian for hundreds of boards, kernels, and configurations.

Armbian isn’t just an operating system. It’s an automated production platform for embedded Linux.

What is actions.armbian.com?

actions.armbian.com is Armbian’s public automation dashboard. It shows the real-time status of the workflows that power the project:

Image builds
Infrastructure maintenance
Package and repository updates
Testing and validation
Data generation for tools and download pages

All of this is driven by GitHub Actions, running on Armbian’s own infrastructure and cloud runners.

In simple terms:

If Armbian were a factory, actions.armbian.com would be the live dashboard showing which machines are running, which are done, and which need attention.

Why does this matter to end users?

Even if you never write code, this system directly impacts you:

Reliability: Builds are reproducible and verified automatically
Fresh images: New kernels, fixes, and board support are rolled out faster
Stability: Failures are detected early, before broken images reach users
Scale: Armbian can support hundreds of boards without manual work

Without this automation, Armbian simply couldn’t exist in its current form.

What can you see on the site?

When you open actions.armbian.com, you’ll find:

A list of workflows and jobs
Their current state (success, failed, running)
Execution time and timestamps
Links to detailed logs and JSON outputs

This transparency is rare in open-source OS projects. You are literally watching Armbian being built in real time.

From code to your SD card

Here’s what typically happens behind the scenes:

A developer updates code (kernel patches, board definitions, build scripts)
A workflow starts automatically
The system prepares a build environment
Kernels and packages are compiled
OS images are built
Checks and validations are executed
Results appear on actions.armbian.com
If certain processes are green, images are published

This process runs thousands of times per month and is fully automated. From another perspective, our servers perform the equivalent of ten years of continuous compute time in a single calendar year.

Why Armbian needs this level of automation

Armbian is not a single OS for one device. It supports:

ARM, RISC-V, and x86
Dozens of SoCs
Hundreds of boards
Multiple kernels (legacy, current, edge)
Multiple Debian and Ubuntu releases

Manually maintaining this would be impossible. Action script behind is what makes Armbian scalable.

Not just builds – a full ecosystem

The automation system also handles:

Generation of download metadata
Repository synchronization
Mirror health checks
Infrastructure housekeeping
Statistics and reporting
Future tools like Armbian Imager integration

It is the backbone of Armbian’s modern platform approach.

Should users look at it?

Most users don’t need to.
But when something goes wrong, it becomes incredibly valuable:

Why is my board image missing?
Why did today’s build fail?
Is Armbian currently building new images?

The answers are often already visible there.

In short

actions.armbian.com is the heart of Armbian’s automation.

It represents:

Transparency
Quality control
Engineering discipline
And the reason Armbian can support such a massive hardware ecosystem

You may never interact with it directly, but every Armbian image you use was born there.

ARMBIAN: Beat the heat

Michael Robinson — 2026-07-29T15:13:05+00:00

Why thermal management is non-negotiable for modern SBCs

By Michael Robinson

As Western Europe endures severe summer conditions with climate monitors at the Copernicus Climate Change Service reporting unprecedented regional heatwaves and extreme highs stretching across the continent ambient indoor conditions are testing the limits of self-hosted edge hardware.

In unconditioned workspaces, home server racks, and industrial enclosures, rising ambient air temperatures erode the thermal headroom that single-board computers (SBCs) rely on. Modern System-on-Chips (SoCs) such as the Rockchip RK3588, Allwinner, and Broadcom platforms integrate high-performance CPUs, GPUs, and neural processing units on a single piece of silicon. When summer weather drives up ambient baselines, that extreme component density makes uncooled hardware uniquely vulnerable to severe throttling and instability.

Why ambient heat hits SBCs harder

Unlike desktop workstations equipped with liquid cooling loops or expansive fan arrays, small form-factor boards operate under strict physical constraints:

High component density: High-performance SoCs integrate the processor cores, graphics processing unit, memory controller, and power management IC onto a compact footprint.
Bare-board defaults: Most SBCs ship without pre-mounted thermal hardware, depending almost entirely on passive air movement around the bare board.
Eroded thermal headroom: Passive cooling relies on heat transferring from the warm chip into cooler surrounding air. As room temperatures climb during a heatwave, that temperature gap shrinks, causing the board&aposs baseline resting temperature to rise right along with the room.

When workload demands push internal silicon temperatures past safety limits, the hardware triggers automatic protective mechanisms. The system governor scales down operating frequencies and voltages to protect the silicon from permanent damage a process known as thermal throttling.

Thermal throttling: The silent bottleneck

Thermal throttling rarely triggers explicit desktop warnings or system crashes. Instead, it degrades board behavior behind the scenes:

Degraded throughput: Code compilation, container builds, and database queries take significantly longer as clock speeds drop under sustained load.
Latency spikes and stutter: Frame drops occur during media playback, desktop rendering, or video stream processing.
System instability: Prolonged high-temperature operation can destabilize power delivery components, causing unexpected kernel panics or filesystem corruption.

When a self-hosted node or edge gateway exhibits sluggish performance on hot summer afternoons, reduced thermal headroom rather than a software bug is frequently the root cause.

Real-world impact: High-performance SoCs

Under sustained computational workloads, powerful SBCs like the Orange Pi 5 (powered by the Rockchip RK3588S SoC) clearly demonstrate the need for thermal dissipation hardware:

Without thermal protection: Operating as a bare board under full CPU or NPU load, the SoC quickly reaches its built-in thermal threshold, forcing steep frequency cuts within seconds.
With passive cooling: Mounting a finned aluminum heatsink provides the added surface area needed to dissipate heat into ambient air, helping the board sustain target frequencies through typical day-to-day tasks.
With active cooling: Adding forced airflow via a low-noise fan sweeps hot air clear of the heatsink fins, completely eliminating throttling even during multi-threaded stress testing or local AI workloads.

Choosing the right thermal strategy

Passive radiative heatsinks: Extruded aluminum or copper blocks rely on natural air convection. They are silent and durable, making them ideal for headless servers provided the board isn&apost trapped in a sealed plastic case that acts as an insulator.
Active cooling (heatsink + fan): Combining a heatsink with a dedicated fan uses forced air to clear heat buildup. This approach is recommended for heavy continuous workloads like video encoding, local machine learning models, or continuous software builds.
Full-body aluminum enclosures: These designs turn the entire outer chassis into a heat sink, using internal thermal pads to transfer heat directly away from the SoC.

Mounting best practices

Always use thermal interface material (TIM): Microscopic air gaps between metal and silicon trap heat. Apply a thin thermal pad or an even layer of thermal paste to establish proper conductive contact.
Clean contact surfaces: Clear away oils or residue on the SoC die using high-purity isopropyl alcohol before mounting hardware.
Ensure even pressure: Verify that the heatsink sits flat and makes uniform contact across the top of the chip.
Cool secondary heat sources: Under heavy continuous operation, secondary components such as power management ICs (PMICs), system RAM, and NVMe drives also benefit from smaller passive heatsinks.

Conclusion

As seasonal temperature extremes become more common, proactive thermal management is essential for maintaining server stability and device longevity. Adding proper cooling hardware protects your single-board computers from silent performance bottlenecks and ensures reliable operation through summer heatwaves.

Pardus: Pardus 25.2 Sürümü Yayınlandı!

Mohammad Niaei — 2026-07-29T13:35:01+00:00

TÜBİTAK BİLGEM tarafından geliştirilen Pardus’un 25.2 sürümü yayınlandı. Bu sürüm, Pardus 25 ailesinin ikinci ara güncellemesi olarak kullanıcılarla buluşuyor.

GreenboneOS: Patch Now! Back-to-Back Synacor Zimbra Updates Fix Two Sets of Critical Vulnerabilities

Joseph Lee — 2026-07-29T12:31:09+00:00

In July 2026, Zimbra released two security patches for multiple vulnerabilities affecting the Classic Web Client and other components of Zimbra Collaboration Suite (ZCS). Version 10.1.19 addressed a stored cross-site scripting (XSS) flaw that has not been assigned a CVE. Version 10.1.20 fixed a command-injection issue in the SNMP monitoring component, four additional stored XSS […]

GreenboneOS: CVE-2026-16232: Check Point SmartConsole Login Process Actively Exploited and More

Joseph Lee — 2026-07-28T13:58:10+00:00

Check Point has published three new security advisories addressing flaws in Security Management Server (SMS), Multi-Domain Management (MDM), and other Gaia-related components. The highest-priority issue, CVE-2026-16232 (CVSS 9.1), is an actively exploited authentication bypass affecting Check Point SmartConsole in SMS and MDM products. CVE-2026-16232 was published on July 22nd, 2026, and added to CISA’s Known […]

Univention Corporate Server: UCS 5.3 Alpha Release: A Preview of the Updated Operating Environment for Univention Nubus on Debian 13 “Trixie”

Ingo Steuwer — 2026-07-28T11:43:44+00:00

The first alpha release of UCS 5.3 is now available, making the next version of the operating environment for Nubus tangible. The focus of this release is on updating the Debian base. At the same time, an important organizational milestone is being prepared: the entry into force of the separate maintenance cycles for Nubus and UCS. This article provides an overview of the current status, the planned next steps, and the path to the stable release.

Debian 13 ``Trixie`` as the New Base

With UCS 5.3, the operating environment for Nubus is being updated to Debian 13 “Trixie”, the central technical change of this release. No further major technical adjustments to the operating environment are planned for UCS 5.3 itself. Instead, new features and further developments at the IAM level will be provided, as intended in the course of the new maintenance separation – through independent Nubus updates, regardless of the release rhythm of the operating environment.

Separate Maintenance Cycles Take Effect

With the release of UCS 5.3, the announced separation of the maintenance commitments for Nubus and UCS officially takes effect: Instead of a coupled maintenance for the operating environment and IAM functionality, there will in future be two independent cycles. Both continue to apply with the promise of stable, backward-compatible maintenance and optionally long durations (LTS), but they follow the independent release rhythms of UCS and Nubus respectively. This makes updates to the operating environment more predictable and, at the same time, allows new Nubus features to become available faster, without having to wait for major UCS releases. The background and details on this can be found in the article “Separate maintenance cycles for Nubus and UCS”.

Status of the Alpha Release

The development status of UCS 5.3 is already advanced: All components can be installed and tested. This makes the alpha release well suited for gaining initial experience with Debian 13 as the new base and for reviewing your own extensions or integrations.

It is important to classify this correctly: This is an alpha release. It is expressly not intended for productive use, and there will be no update path to a later stable version. Installations of the alpha release serve exclusively for testing and evaluation purposes.

Outlook: Further Alpha and Beta Releases

Over the coming months, further alpha releases and subsequently beta releases of UCS 5.3 are planned, with which the level of maturity will gradually increase. The exact schedule for the stable release will be communicated together with one of the upcoming releases.

Download and Further Information

UCS 5.3 Alpha is now available for download. For more information about the included changes, please refer to the help article.

Feedback on the alpha release is expressly welcome – via help.univention.com or your respective contact person at Univention.

Der Beitrag UCS 5.3 Alpha Release: A Preview of the Updated Operating Environment for Univention Nubus on Debian 13 “Trixie” erschien zuerst auf Univention.

VyOS: VyOS Project June & July 2026 Update

Daniil Baturin — 2026-07-28T10:45:00+00:00

Hello, Community!

The June and July development update is here. Over the past two months, the VyOS team focused on security and compliance enhancements, community-driven improvements, platform updates, and customer engagement.

On the security side, we laid the groundwork for FIPS compliance, added post-quantum key exchange to IPsec, and started publishing SBOM artifacts for full supply-chain transparency. The community also stepped in with some hard-won fixes, from a zone-based firewall bug in VRF configurations to a route-target quirk that was causing needless traffic interruptions on every commit.

Deepin: 独立开发者又一力作！微信「分身大师」上线，电脑微信一键多开

xiaofei — 2026-07-28T02:07:52+00:00

Sorry, this entry is only available in 中文.

ARMBIAN: Github Highlights

Michael Robinson — 2026-07-28T01:16:05+00:00

This week&aposs work centers on new board enablement and platform maintenance, kernel and U-Boot refresh across Rockchip and Sunxi, and CI/build infrastructure improvements.

Board support expanded with the addition of Sovol Zero, SV08, and SV08 Max on the H616 platform, alongside mainline and edge enablement for the Recomputer RK3576 devkit. BeagleY-AI features were forward-ported through kernel 7.2, the Mekotronics R58S2 gained rockusb recovery-key support, and the NanoPi R3S received an ethernet alias. Vendor logos and board imagery were also refreshed on the website.

On the kernel and bootloader side, the cix-p1 edge kernel moved to 7.1.5 with refreshed patches, meson64 dropped multiple upstreamed patches, and rk3328 DMC was repaired for newer kernels. U-Boot bumps landed for Rockpi-4A and EasePi-A2/R2 at v2026.07, rk35xx vendor patches were isolated from 2024.03 boards, and Rockchip vendor UFS support was corrected. Several BigTreeTech CB1 and sunxi issues were resolved, including WiFi power sequencing and PWM driver race conditions.

Infrastructure changes introduced a BTRFS_CHECKSUM build switch and a DOCKER_FORCE_PULL option, parallelized patch rewriting up to nproc, and raised the CI artifact build timeout from 60 to 120 minutes. Runner cleanup logic now installs and selects docker buildx by flavor, stable-track dispatch inputs were trimmed, and the AI README generator was made feedback-aware while forbidden from inventing paths.

#Armbian #EmbeddedLinux #Rockchip #Sunxi #UBoot #CI

Changes

Add a BTRFS_CHECKSUM build switch for choosing the checksum algorithm. by @dlitz in armbian/build#10288
add parallel patching switches. by @EvilOlaf in armbian/documentation#945
Add Sovol vendor logo and board images (Zero, SV08, SV08 Max). by @lexfrei in armbian/armbian.github.io#366
Add support for Sovol Zero, SV08 and SV08 Max (H616). by @lexfrei in armbian/build#10255
arduino: fetch qcombin at image-build time, not config time. by @igorpecovnik in armbian/build#10226
Build-Switches: document BTRFS_CHECKSUM. by @dlitz in armbian/documentation#946
Build-Switches: document DOCKER_FORCE_PULL. by @igorpecovnik in armbian/documentation#943
ci: force a fresh Docker image pull on manual builds (default yes). by @igorpecovnik in armbian/ci#30
ci: raise artifact build timeout 60 -> 120 minutes. by @igorpecovnik in armbian/ci#33
ci: stable-track cleanup — reuse version + trim dispatch inputs. by @igorpecovnik in armbian/ci#31
ci: unite & clean the armbian-* build configs (fix apps OCI cache). by @igorpecovnik in armbian/ci#32
cix-p1: edge: update patches for 7.1.5, remove version pin. by @EvilOlaf in armbian/build#10297
cix-p1: pin edge kernel to v7.1.4 (Panthor patchset breaks on 7.1.5). by @igorpecovnik in armbian/build#10282
cli-patch: generalize to-git push (PUSH_TO_GITHUB / PUSH_TO_REPO), for u-boot too. by @igorpecovnik in armbian/build#10193
docker: add DOCKER_FORCE_PULL=yes to bypass the base-image pull cache. by @igorpecovnik in armbian/build#10251
docker: warn when buildx is missing, and reap leftover per-build images. by @iav in armbian/build#10239
Fix Darwin Docker Host Arch. by @Grippy98 in armbian/build#10279
fix(patching): render patch summary tables at the reader&aposs real terminal width. by @iav in armbian/build#10262
fix(sovol): reuse CB1 u-boot board patches on Sovol H616 boards. by @lexfrei in armbian/build#10285
fix(sunxi): use named i2c-gpio properties on BigTreeTech CB1. by @lexfrei in armbian/build#10287
generate_targets: build rootfs-riscv64 on the native ubuntu-24.04-riscv runner. by @igorpecovnik in armbian/armbian.github.io#363
k3-beagle: forward port BeagleY-AI features through 7.2. by @Grippy98 in armbian/build#10266
k3: handle optional boot firmware artifacts cleanly. by @Grippy98 in armbian/build#10272
k3: restore required edge platform drivers. by @Grippy98 in armbian/build#10273
mainline: bump bleedingedge to 7.2-rc4. by @EvilOlaf in armbian/build#10253
mekotronics-r58s2: Make recovery key enter rockusb mode. by @HeyMeco in armbian/build#10257
meson64-6.18: drop upstreamed pinctrl-meson can_sleep patch. by @igorpecovnik in armbian/build#10277
meson64-7.1: drop 2 upstreamed patches + rebase aiu HDMI fix onto v7.1.5. by @igorpecovnik in armbian/build#10278
nanopi-r3s: Add "ethernet1" alias for the LAN port. by @dlitz in armbian/build#10275
orangepi5: add AP6275P support to non-vendor kernels. by @efectn in armbian/build#10289
readme-updater: forbid inventing directory/file paths in generated README. by @igorpecovnik in armbian/armbian.github.io#369
readme-updater: make the AI README generator feedback-aware. by @igorpecovnik in armbian/armbian.github.io#365
realtek-rtd1619b: don&apost error on int/pointer conversions (gcc >= 14). by @igorpecovnik in armbian/build#10283
recomputer-rk3576-devkit: edge/mainline enablement. by @rpardini in armbian/build#10235
recomputer: drop &aposDevkit&apos from BOARD_NAME. by @igorpecovnik in armbian/build#10256
release-targets: blacklist sk-am62-lp from stable builds. by @igorpecovnik in armbian/armbian.github.io#368
release-targets: drop deprecated DESKTOP_ENVIRONMENT_CONFIG_NAME / DESKTOP_APPGROUPS_SELECTED. by @igorpecovnik in armbian/armbian.github.io#362
Revert "odroidc2: u-boot: use minimal patchset for v22.01 u-boot". by @ssilnicki-dev in armbian/build#10265
rewrite patches: speed up the process up to nproc. by @EvilOlaf in armbian/build#10163
rk35xx u-boot: isolate 2024.10-only vendor patches from the 2024.03 boards. by @igorpecovnik in armbian/build#10281
rockchip64-6.18: overlays: rewrite README.md. by @EvilOlaf in armbian/build#10295
rockchip64: add NanoPi NEO3 onboard fan (CON4) pwm-fan overlay. by @tenox7 in armbian/build#10291
rockchip64: fix rk3328 dmc driver on newer kernels. by @paolosabatino in armbian/build#10261
rockpi-4a: bump u-boot to v2026.07 with btrfs root and working SPI. by @iav in armbian/build#10260
runner-clean: install docker buildx if not present. by @igorpecovnik in armbian/actions#30
runner-clean: pick buildx package by docker flavor (docker-ce vs docker.io). by @igorpecovnik in armbian/actions#32
runner-clean: simplify buildx install to docker-buildx only (drop jammy). by @igorpecovnik in armbian/actions#31
SpacemiT K1: Enable PCIe on OrangePi R2S and add other misc thermal spi and pcie fixups. by @pyavitz in armbian/build#10269
starfive2-vendor: fix img-rogue build on GNU Make 4.4 (trixie). by @igorpecovnik in armbian/build#10286
sunxi64: build sunxi pwm driver in to fix ac300 EPHY probe race. by @lexfrei in armbian/build#10242
sunxi: cb1: fix wifi pwrseq clock name so the 32k LPO is actually enabled. by @lexfrei in armbian/build#10240
sunxi: cb1: stop exposing wifi power lines as gpio LEDs. by @lexfrei in armbian/build#10241
sunxi: drop upstreamed kernel patches failing as &apospreviously applied&apos (6.12/6.18/7.0). by @igorpecovnik in armbian/build#10276
sunxi: fix BigTreeTech CB1 patches failing to apply (all kernel branches). by @igorpecovnik in armbian/build#10252
u-boot: Rockchip vendor u-boot fix UFS being utterly broken. by @HeyMeco in armbian/build#10254
uboot: bump EasePi-A2/R2 mainline U-Boot to v2026.07 and add resolute release support. by @ifroncy01 in armbian/build#10274
Update vendor logo. by @igorpecovnik in armbian/armbian.github.io#364
uwe5622: switch to unified driver in dedicated repo. by @EvilOlaf in armbian/build#10113

Qubes: XSAs released on 2026-07-28

Qubes — 2026-07-28T00:00:00+00:00

The Xen Project has released one or more Xen security advisories (XSAs). The security of Qubes OS is affected.

XSAs that DO affect the security of Qubes OS

The following XSAs do affect the security of Qubes OS:

XSAs that DO NOT affect the security of Qubes OS

The following XSAs do not affect the security of Qubes OS, and no user action is necessary:

XSA-495: Denial of service only. Shadow paging is disabled in Qubes OS at build time.
XSA-496: Denial of service only. Affects only Xen 4.21 and higher; Qubes OS 4.3 uses Xen 4.19.
XSA-497: Qubes OS does not use pygrub.
XSA-499: Denial of service only.
XSA-501: Qubes OS has grant tables v2 disabled.
XSA-502: Qubes OS does not use vnuma.
XSA-503: Allows leaking internal information about a qube only to itself, not other qubes.
XSA-504: Viridian is not enabled in Qubes OS.
XSA-508: Qubes OS does not use pygrub.

About this announcement

Qubes OS uses the Xen hypervisor as part of its architecture. When the Xen Project publicly discloses a vulnerability in the Xen hypervisor, they issue a notice called a Xen security advisory (XSA). Vulnerabilities in the Xen hypervisor sometimes have security implications for Qubes OS. When they do, we issue a notice called a Qubes security bulletin (QSB). (QSBs are also issued for non-Xen vulnerabilities.) However, QSBs can provide only positive confirmation that certain XSAs do affect the security of Qubes OS. QSBs cannot provide negative confirmation that other XSAs do not affect the security of Qubes OS. Therefore, we also maintain an XSA tracker, which is a comprehensive list of all XSAs publicly disclosed to date, including whether each one affects the security of Qubes OS. When new XSAs are published, we add them to the XSA tracker and publish a notice like this one in order to inform Qubes users that a new batch of XSAs has been released and whether each one affects the security of Qubes OS.

Qubes: QSB-116: Multiple Xen issues (XSA-500, XSA-505, XSA-506, XSA-507)

Qubes — 2026-07-28T00:00:00+00:00

We have published Qubes Security Bulletin (QSB) 116: Multiple Xen issues (XSA-500, XSA-505, XSA-506, XSA-507). The text of this QSB and its accompanying cryptographic signatures are reproduced below, followed by a general explanation of this announcement and authentication instructions.

Qubes Security Bulletin 116

             ---===[ Qubes Security Bulletin 116 ]===---

                              2026-07-28

       Multiple Xen issues (XSA-500, XSA-505, XSA-506, XSA-507)

User action
------------

Continue to update normally [1] in order to receive the security updates
described in the "Patching" section below. No other user action is
required in response to this QSB.

Summary
--------

On 2026-07-28, the Xen Project published the security advisories below.

XSA-500 [3] "grant-table: type confusion in grant-copy":

| When grant-copy operations are processed, the respective grant may or
| may not already be in use by another operation (a mapping or another
| copy). For all copy operations the referenced guest frame is looked
| up. When another operation is already active for the grant (the grant
| is "pinned"), what is being supplied back to actually carry out
| permission checks and copy operation may not be consistent: The
| permission check may be carried out on a page different from the one
| involved in the copy.


XSA-505 [4] "evtchn: Race between FIFO expand and reset":

| The EVTCHNOP_expand_array hypercall checks for whether FIFO event
| channels are enabled, but without holding the correct lock. It can
| race with EVTCHNOP_reset, resulting in deferencing a NULL pointer.


XSA-506 [5] "correct buffer checks for DM_OP hypercalls":

| Parts of the DM_OP handling code assumes the caller has provided the
| required number of buffers for the given operation without any
| checking being done. As a result, certain operations might access
| stack rubble as structures are possibly uninitialized.

XSA-507 [6] "PoD: Don't try to reclaim special pages":

| A guest started with Populated on Demand enabled (PoD) can attempt to
| reclaim pages which aren't regular guest RAM. This can cause
| corruption of memory management state in Xen.

Impact
-------

XSA-500 and XSA-507: A malicious qube may be able to compromise
Qubes OS.

XSA-505: A malicious PV qube [7] may be able to compromise Qubes OS. The
same impact applies to stubdomains for HVM qubes [8], but in this case
an attacker would first have to discover and exploit an independent
vulnerability (in QEMU) in order to gain access to the stubdomain.

XSA-506: The stubdomain for an HVM qube may be able to leak data from
other qubes in the system. In order to exploit this vulnerability, an
attacker would first have to discover and exploit an independent
vulnerability (in QEMU) in order to gain access to the stubdomain.

Affected systems
-----------------

XSA-500: All systems are affected.

XSA-505: Systems with either PV qubes or stubdomains for HVM qubes (or
both) are affected, but the vulnerability is easier to exploit on
systems with PV qubes. In the default Qubes OS configuration, there are
no PV qubes, but sys-net and sys-usb are HVM qubes that have
stubdomains. This means that the vulnerability is more difficult to
exploit in the default Qubes OS configuration, but if a user has
manually created PV qubes in a particular system, the vulnerability will
be easier to exploit on that system.

XSA-506: Systems with untrusted HVM qubes are affected. In the default
configuration of Qubes OS, sys-net and sys-usb are HVM qubes and are
considered to be untrusted.

XSA-507: Systems are affected if they have qubes that are included in
memory balancing but that don't advertise memory hotplug support. This
includes malicious HVM qubes with memory balancing enabled, as well as
templates and standalones that use in-qube kernels and that have memory
balancing enabled. The default Qubes OS configuration is not affected,
nor are commonly-used HVM qubes like Windows, since they don't have
memory balancing enabled.

Patching
---------

The following packages contain security updates that address the
vulnerabilities described in this bulletin:

  For Qubes 4.3, in dom0:
  - Xen packages, version 4.19.5-2

These packages will migrate from the security-testing repository to the
current (stable) repository over the next two weeks after being tested
by the community. [2] Once available, the packages should be installed
via the Qubes Update tool or its command-line equivalents. [1]

Dom0 must be restarted afterward in order for the updates to take
effect.

If you use Anti Evil Maid, you will need to reseal your secret
passphrase to new PCR values, as PCR18+19 will change due to the new Xen
binaries.

Credits
--------

See the original Xen Security Advisories. [3][4][5][6]

References
-----------

[1] https://doc.qubes-os.org/en/latest/user/how-to-guides/how-to-update.html
[2] https://doc.qubes-os.org/en/latest/user/downloading-installing-upgrading/testing.html
[3] https://xenbits.xen.org/xsa/advisory-500.html
[4] https://xenbits.xen.org/xsa/advisory-505.html
[5] https://xenbits.xen.org/xsa/advisory-506.html
[6] https://xenbits.xen.org/xsa/advisory-507.html
[7] A PV qube is a qube that is running with virt_mode set to "pv."
[8] For each qube that is running with virt_mode set to "hvm," there's a
    small Xen-internal helper VM running alongside it, in which QEMU is
    executed to provide device emulation for that qube. This helper VM
    runs in PV mode and is called a "stubdomain."

--
The Qubes Security Team
https://www.qubes-os.org/security/

Source: qsb-116-2026.txt

Marek Marczykowski-Górecki’s PGP signature

Source: qsb-116-2026.txt.sig.marmarek

Simon Gaiser (aka HW42)’s PGP signature

Source: qsb-116-2026.txt.sig.simon

What is the purpose of this announcement?

The purpose of this announcement is to inform the Qubes community that a new Qubes security bulletin (QSB) has been published.

What is a Qubes security bulletin (QSB)?

A Qubes security bulletin (QSB) is a security announcement issued by the Qubes security team. A QSB typically provides a summary and impact analysis of one or more recently-discovered software vulnerabilities, including details about patching to address them.

Why should I care about QSBs?

QSBs tell you what actions you must take in order to protect yourself from recently-discovered security vulnerabilities. In most cases, security vulnerabilities are addressed by updating normally. However, in some cases, special user action is required. In all cases, the required actions are detailed in QSBs.

What are the PGP signatures that accompany QSBs?

A PGP signature is a cryptographic digital signature made in accordance with the OpenPGP standard. PGP signatures can be cryptographically verified with programs like GNU Privacy Guard (GPG). The Qubes security team cryptographically signs all QSBs so that Qubes users have a reliable way to check whether QSBs are genuine. The only way to be certain that a QSB is authentic is by verifying its PGP signatures.

Why should I care whether a QSB is authentic?

A forged QSB could deceive you into taking actions that adversely affect the security of your Qubes OS system, such as installing malware or making configuration changes that render your system vulnerable to attack. Falsified QSBs could sow fear, uncertainty, and doubt about the security of Qubes OS or the status of the Qubes OS Project.

How do I verify the PGP signatures on a QSB?

The following command-line instructions assume a Linux system with git and gpg installed. (For Windows and Mac options, see OpenPGP software.)

Obtain the Qubes Master Signing Key (QMSK), e.g.:

$ gpg --fetch-keys https://keys.qubes-os.org/keys/qubes-master-signing-key.asc
gpg: directory '/home/user/.gnupg' created
gpg: keybox '/home/user/.gnupg/pubring.kbx' created
gpg: requesting key from 'https://keys.qubes-os.org/keys/qubes-master-signing-key.asc'
gpg: /home/user/.gnupg/trustdb.gpg: trustdb created
gpg: key DDFA1A3E36879494: public key "Qubes Master Signing Key" imported
gpg: Total number processed: 1
gpg:               imported: 1

(For more ways to obtain the QMSK, see How to import and authenticate the Qubes Master Signing Key.)

View the fingerprint of the PGP key you just imported. (Note: gpg> indicates a prompt inside of the GnuPG program. Type what appears after it when prompted.)

$ gpg --edit-key 0x427F11FD0FAA4B080123F01CDDFA1A3E36879494
gpg (GnuPG) 2.2.27; Copyright (C) 2021 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
   
   
pub  rsa4096/DDFA1A3E36879494
     created: 2010-04-01  expires: never       usage: SC
     trust: unknown       validity: unknown
[ unknown] (1). Qubes Master Signing Key
   
gpg> fpr
pub   rsa4096/DDFA1A3E36879494 2010-04-01 Qubes Master Signing Key
 Primary key fingerprint: 427F 11FD 0FAA 4B08 0123  F01C DDFA 1A3E 3687 9494

Important: At this point, you still don’t know whether the key you just imported is the genuine QMSK or a forgery. In order for this entire procedure to provide meaningful security benefits, you must authenticate the QMSK out-of-band. Do not skip this step! The standard method is to obtain the QMSK fingerprint from multiple independent sources in several different ways and check to see whether they match the key you just imported. For more information, see How to import and authenticate the Qubes Master Signing Key.

Tip: After you have authenticated the QMSK out-of-band to your satisfaction, record the QMSK fingerprint in a safe place (or several) so that you don’t have to repeat this step in the future.

Once you are satisfied that you have the genuine QMSK, set its trust level to 5 (“ultimate”), then quit GnuPG with q.

gpg> trust
pub  rsa4096/DDFA1A3E36879494
     created: 2010-04-01  expires: never       usage: SC
     trust: unknown       validity: unknown
[ unknown] (1). Qubes Master Signing Key
   
Please decide how far you trust this user to correctly verify other users' keys
(by looking at passports, checking fingerprints from different sources, etc.)
   
  1 = I don't know or won't say
  2 = I do NOT trust
  3 = I trust marginally
  4 = I trust fully
  5 = I trust ultimately
  m = back to the main menu
   
Your decision? 5
Do you really want to set this key to ultimate trust? (y/N) y
   
pub  rsa4096/DDFA1A3E36879494
     created: 2010-04-01  expires: never       usage: SC
     trust: ultimate      validity: unknown
[ unknown] (1). Qubes Master Signing Key
Please note that the shown key validity is not necessarily correct
unless you restart the program.
   
gpg> q

Use Git to clone the qubes-secpack repo.

$ git clone https://github.com/QubesOS/qubes-secpack.git
Cloning into 'qubes-secpack'...
remote: Enumerating objects: 4065, done.
remote: Counting objects: 100% (1474/1474), done.
remote: Compressing objects: 100% (742/742), done.
remote: Total 4065 (delta 743), reused 1413 (delta 731), pack-reused 2591
Receiving objects: 100% (4065/4065), 1.64 MiB | 2.53 MiB/s, done.
Resolving deltas: 100% (1910/1910), done.

Import the included PGP keys. (See our PGP key policies for important information about these keys.)

$ gpg --import qubes-secpack/keys/*/*
gpg: key 063938BA42CFA724: public key "Marek Marczykowski-Górecki (Qubes OS signing key)" imported
gpg: qubes-secpack/keys/core-devs/retired: read error: Is a directory
gpg: no valid OpenPGP data found.
gpg: key 8C05216CE09C093C: 1 signature not checked due to a missing key
gpg: key 8C05216CE09C093C: public key "HW42 (Qubes Signing Key)" imported
gpg: key DA0434BC706E1FCF: public key "Simon Gaiser (Qubes OS signing key)" imported
gpg: key 8CE137352A019A17: 2 signatures not checked due to missing keys
gpg: key 8CE137352A019A17: public key "Andrew David Wong (Qubes Documentation Signing Key)" imported
gpg: key AAA743B42FBC07A9: public key "Brennan Novak (Qubes Website & Documentation Signing)" imported
gpg: key B6A0BB95CA74A5C3: public key "Joanna Rutkowska (Qubes Documentation Signing Key)" imported
gpg: key F32894BE9684938A: public key "Marek Marczykowski-Górecki (Qubes Documentation Signing Key)" imported
gpg: key 6E7A27B909DAFB92: public key "Hakisho Nukama (Qubes Documentation Signing Key)" imported
gpg: key 485C7504F27D0A72: 1 signature not checked due to a missing key
gpg: key 485C7504F27D0A72: public key "Sven Semmler (Qubes Documentation Signing Key)" imported
gpg: key BB52274595B71262: public key "unman (Qubes Documentation Signing Key)" imported
gpg: key DC2F3678D272F2A8: 1 signature not checked due to a missing key
gpg: key DC2F3678D272F2A8: public key "Wojtek Porczyk (Qubes OS documentation signing key)" imported
gpg: key FD64F4F9E9720C4D: 1 signature not checked due to a missing key
gpg: key FD64F4F9E9720C4D: public key "Zrubi (Qubes Documentation Signing Key)" imported
gpg: key DDFA1A3E36879494: "Qubes Master Signing Key" not changed
gpg: key 1848792F9E2795E9: public key "Qubes OS Release 4 Signing Key" imported
gpg: qubes-secpack/keys/release-keys/retired: read error: Is a directory
gpg: no valid OpenPGP data found.
gpg: key D655A4F21830E06A: public key "Marek Marczykowski-Górecki (Qubes security pack)" imported
gpg: key ACC2602F3F48CB21: public key "Qubes OS Security Team" imported
gpg: qubes-secpack/keys/security-team/retired: read error: Is a directory
gpg: no valid OpenPGP data found.
gpg: key 4AC18DE1112E1490: public key "Simon Gaiser (Qubes Security Pack signing key)" imported
gpg: Total number processed: 17
gpg:               imported: 16
gpg:              unchanged: 1
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: depth: 0  valid:   1  signed:   6  trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: depth: 1  valid:   6  signed:   0  trust: 6-, 0q, 0n, 0m, 0f, 0u

Verify signed Git tags.

$ cd qubes-secpack/
$ git tag -v `git describe`
object 266e14a6fae57c9a91362c9ac784d3a891f4d351
type commit
tag marmarek_sec_266e14a6
tagger Marek Marczykowski-Górecki 1677757924 +0100
   
Tag for commit 266e14a6fae57c9a91362c9ac784d3a891f4d351
gpg: Signature made Thu 02 Mar 2023 03:52:04 AM PST
gpg:                using RSA key 2D1771FE4D767EDC76B089FAD655A4F21830E06A
gpg: Good signature from "Marek Marczykowski-Górecki (Qubes security pack)" [full]

The exact output will differ, but the final line should always start with gpg: Good signature from... followed by an appropriate key. The [full] indicates full trust, which this key inherits in virtue of being validly signed by the QMSK.

Verify PGP signatures, e.g.:

$ cd QSBs/
$ gpg --verify qsb-087-2022.txt.sig.marmarek qsb-087-2022.txt
gpg: Signature made Wed 23 Nov 2022 04:05:51 AM PST
gpg:                using RSA key 2D1771FE4D767EDC76B089FAD655A4F21830E06A
gpg: Good signature from "Marek Marczykowski-Górecki (Qubes security pack)" [full]
$ gpg --verify qsb-087-2022.txt.sig.simon qsb-087-2022.txt
gpg: Signature made Wed 23 Nov 2022 03:50:42 AM PST
gpg:                using RSA key EA18E7F040C41DDAEFE9AA0F4AC18DE1112E1490
gpg: Good signature from "Simon Gaiser (Qubes Security Pack signing key)" [full]
$ cd ../canaries/
$ gpg --verify canary-034-2023.txt.sig.marmarek canary-034-2023.txt
gpg: Signature made Thu 02 Mar 2023 03:51:48 AM PST
gpg:                using RSA key 2D1771FE4D767EDC76B089FAD655A4F21830E06A
gpg: Good signature from "Marek Marczykowski-Górecki (Qubes security pack)" [full]
$ gpg --verify canary-034-2023.txt.sig.simon canary-034-2023.txt
gpg: Signature made Thu 02 Mar 2023 01:47:52 AM PST
gpg:                using RSA key EA18E7F040C41DDAEFE9AA0F4AC18DE1112E1490
gpg: Good signature from "Simon Gaiser (Qubes Security Pack signing key)" [full]

Again, the exact output will differ, but the final line of output from each gpg --verify command should always start with gpg: Good signature from... followed by an appropriate key.

For this announcement (QSB-116), the commands are:

$ gpg --verify qsb-116-2026.txt.sig.marmarek qsb-116-2026.txt
$ gpg --verify qsb-116-2026.txt.sig.simon qsb-116-2026.txt

You can also verify the signatures directly from this announcement in addition to or instead of verifying the files from the qubes-secpack. Simply copy and paste the QSB-116 text into a plain text file and do the same for both signature files. Then, perform the same authentication steps as listed above, substituting the filenames above with the names of the files you just created.

AIMS Desktop developers: DebConf26 – Santa Fe, Argentina

jonathan — 2026-07-27T20:12:18+00:00

TL;DR: What a great DebConf! I managed to recharge my Debian batteries, and my talks / BoF sessions all went fine. Already looking forward to DebConf in Japan next year!

DebCamp

The evening before DebCamp started, we had a nice bbq (we taught some locals to call it a “braai” at an organiser’s house and went for a walk around the river as the sun set. It was a very peaceful lead-in to DebCamp.

I set up and sent out the call for Forky desktop artwork:
- https://lists.debian.org/msgid-search/910906f3-7ce4-4884-a49f-4b4a5975471b@debian.org
Had many nice discussions about various Debian topics with all the Debian people around. It’s really fun being around people who are natural problem solvers who care deeply about both technical and social issues. At one point Jonas told me “Holy shit, these people are motivated!” and I appreciate that so much too!

Debian LTS wine

Most of my DebCamp was dedicated to preparing for my demo and main talk that followed at DebConf.
Sadly, we had no loopy this year, I just didn’t have the time, and the people who stepped up to help last year were either overwhelmed with other issues or couldn’t make it. I’ll try to make it happen again for next year by kicking it off long before DC27.

View of Santa Fe city from hotel

DebConf

Talk – Is it even possible to build a truly universal system installer?

In this talk I do a very quick comparison of system installers based on my experience with them. It’s hard to directly compare all of them, since there are so many, and each have their own niche that they attempt to satisfy.

I also introduce Yasi – my attempt to answer the question of whether we could build a universal installer, which can also better cover advanced installations, automated installations and niche setups.

It’s very early days for the project, and I didn’t quite feel ready to share the code with the world, but it was nice that I did a quick demo where I could install a Debian system… and the resulting system actually booted up. *phew*.

This is also going to be my main focus for the mid-term future. I aim to have all the basic partitioning options working by the time Debian 14 (Forky) is released, and by the time Debian 15 is released, I have a long list of features that I aim to have working. So, my timeline for having something that’s generally useful is around a year from now, and in around 3 years it should be a fully fledged installer that should cover a very large amount of Debian use cases and architectures.

Day Trip

For the day trip, we did a tour across Santa Fe, visited Constitución de la Nación Argentina, had lunch where we tried various dishes based on local fish from the river, and then went on a boat ride on the river.

BoF Sessions:

Funding in Free Software Projects: I initially registered this BoF because I’m increasingly concerned about how upstreams are asking for donations in their software. I increased the scope to talk about funding in free software in general. It followed Marga’s talk about funding, which focussed more about how developers are funded in general. We didn’t dive very deep into this, but we certainly need some further discussion (and action) on this within Debian.

Debian Social Team: My most important issue for this team is a carry-over from last year, I want to set up barman (packaged in Debian) for live postgres syncing for our larger databases. For the smaller DBs, doing a daily dump is quite cheap. But for Matrix, it’s very expensive in terms if i/o and CPU, so it would be ideal to do less regular complete dumps and use live replication for the first line of redundancy instead.

Images Team: I wasn’t initially planning to say much during this session, I have some ideas to reduce both size and count of images, without losing any benefits, but I don’t have any work to show for that yet. I ended up talking a lot more than I anticipated, the topics covered were quite good and representative of the current state of Debian images built. I don’t have time to create a full summary, so I suggest checking the etherpad / video recording if you’re interested.

Some more wine variety during the conference dinner

Debianites in the main hacklab

Rosario

I’m spending two days in Rosario before I head home. Exploring a bit, catching up with sleep, finishing this blog post, signing keys and exploring some ideas I made note of during DebConf.

Thank you to the DebConf26 Team!

It was a little surreal not being part of any DebConf team for the first time ever, I’ve just been too focussed on getting Yasi ready for my talk (no regrets!). I hope to be more involved again next year, in the meantime, I’m very grateful to everyone who has made this happen, you did a stellar job! I hope to see many of you again next year in Japan!

ZEVENET: How to Load Balance Moodle for High Availability: Architecture, Sessions, and Security

Isabel Perez — 2026-07-27T12:13:27+00:00

A Moodle deployment that performs flawlessly with 20,000 users can easily collapse under the load of 100,000 users on exam day or when course registration opens. The issue isn’t Moodle itself. It’s that, in a single-server deployment, everything (the web application, user sessions, database, and uploaded files) runs on the same machine. Once that server runs out of CPU or memory, or simply goes offline for maintenance, there’s nowhere else for the workload to go.

The obvious answer is to add a load balancer. The correct answer, however, is more nuanced. A load balancer distributes incoming connections, but it doesn’t automatically turn Moodle into a highly available platform. Unless every server shares the same sessions, database, and file storage, all you’ve really done is spread the problem across multiple machines.

What Is Load Balancing in Moodle?

Load balancing in Moodle is the process of distributing user requests across multiple Moodle web servers through a single virtual IP address. The load balancer continuously checks the health of each node and sends traffic only to servers that are available, ensuring that a failed or overloaded server doesn’t interrupt access for students and teachers.

Why Moodle Needs Load Balancing

Traffic spikes: Exams with a common start time, enrollment periods, and grade publication can generate sudden bursts of concurrent traffic.
Zero-downtime maintenance: Updating or patching a server shouldn’t require taking the entire learning platform offline.
Growing numbers of concurrent users: A single server can only handle a finite number of simultaneous connections.
TLS encryption: Managing certificates and TLS decryption on every web server adds unnecessary overhead that can be centralized at the load balancer.

The Real Architecture Behind a Highly Available Moodle Deployment

Moodle’s own documentation explicitly states that, in a multi-server deployment, all web servers must share the same cache, database, and file storage. If any of these components is missing, high availability exists only in theory.

The Load Balancer (ADC)

The Application Delivery Controller (ADC) accepts incoming connections through a virtual IP address, performs health checks on every Moodle node, and decides which server should handle each request. It is also the natural place to terminate TLS connections and enforce security policies before traffic reaches the Moodle application.

Multiple Moodle Web Servers

Every node must run the same Moodle version, include the same plugins, and use an identical configuration. If one server contains plugins or configuration that another does not, user experience becomes unpredictable depending on which node handles the request.

Shared Database

All Moodle web servers must connect to the same database, or to a clustered database infrastructure with failover capabilities. While the load balancer eliminates the single point of failure at the web layer, it does not remove the database as a potential single point of failure.

Shared moodledata

The moodledata directory stores uploaded files, backups, and generated content. It must reside on shared storage that is accessible from every web server. Otherwise, a file uploaded through one node won’t exist when the user’s next request is served by another node.

Shared Sessions and Cache

This is where many deployments fail.

Moodle supports Redis and Memcached as shared session stores across multiple nodes. Without shared sessions, users may appear to be logged out simply because their next request is handled by a different server. Redis Cluster also allows this layer to scale horizontally while providing its own built-in failover capabilities.

Why the Load Balancer Isn’t the Whole Solution

Removing the single point of failure from the web layer is only the first step. If the database, Redis, or moodledata still relies on a single server, that server remains the weak link capable of bringing down the entire platform.

How to Implement Load Balancing in Moodle

Prepare identical Moodle nodes using the same version, plugins, and configuration.
Configure a shared database and shared moodledata storage.
Create an HTTPS virtual service using the public IP address and port that users will access.
Add the Moodle servers as backend nodes for the virtual service.
Configure application-level health checks rather than relying solely on open-port checks.
Choose the appropriate load-balancing algorithm:
- Round Robin for identical servers.
- Least Connections when request duration varies.
- Weighted when backend servers have different capacities.
Enable session persistence (sticky sessions) to reduce contention in the shared session store and keep each user’s requests on the same node.
Configure SSL offloading. When TLS is terminated at the load balancer, Moodle requires $CFG->sslproxy If the internal and external URLs differ, $CFG->reverseproxy must also be configured. Every node should use the same public URL in $CFG->wwwroot
Preserve the client’s real IP address using X-Forwarded-For, while maintaining a well-defined list of trusted proxies.
Make the load balancer itself highly available by deploying it as a two-node cluster with a shared virtual IP and synchronized configuration. Otherwise, the load balancer simply becomes the new single point of failure.

What Load Balancing Alone Doesn’t Solve

Distributing traffic across multiple servers doesn’t protect those servers from attacks. Adding that protection separately also introduces costs that are often underestimated.

A production Moodle deployment requires more than load balancing alone:

Centralized TLS certificate management.
A Web Application Firewall (WAF) for HTTP and HTTPS traffic.
Protection against OWASP Top 10 attack patterns.
Bot and brute-force protection for the login page.
Rate limiting for login requests and file uploads.
DDoS mitigation.
Centralized logging and traffic visibility across all nodes.
High availability for the load balancer itself, preventing it from becoming the new single point of failure.

In practice, each of these capabilities typically means deploying, managing, and maintaining a separate tool, console, and operational workflow if they’re implemented independently.

Why an ADC with an Integrated WAF Changes the Equation

When you consider everything required to support the architecture above, building a highly available Moodle deployment with standalone tools means operating, at a minimum, a load balancer, a certificate management solution, a WAF, a rate-limiting service, and a centralized logging platform—each with its own learning curve, update cycle, and potential point of failure if left unattended.

SKUDONET delivers the same architecture as a single integrated platform:

Load balancing and application-aware health checks for Moodle nodes, supporting the algorithms described above (Round Robin, Least Connections, and Weighted).
Centralized SSL offloading, allowing certificates to be managed from a single location instead of on every web server.
An integrated WAF that protects against the OWASP Top 10, bots, and brute-force attacks without requiring a separate security product.
Built-in rate limiting that can be applied directly to login endpoints and file uploads, the most exposed components of any public Moodle deployment.
Native high availability for the ADC itself through clustering, ensuring that the availability layer doesn’t become the weakest link.
A single pane of glass for monitoring traffic, blocked threats, and node health, eliminating the need to correlate logs from multiple systems during an incident.

The advantage isn’t that SKUDONET performs load balancing better than HAProxy or NGINX—both are technically robust solutions that have been powering Moodle deployments for years. The difference is that, with SKUDONET, load balancing, security, and high availability for the load balancer itself are built into the same platform from day one.

For teams that don’t want to become infrastructure integrators in addition to Moodle administrators, that translates into significantly less operational overhead and a much smaller maintenance burden.

Comparing Moodle Load Balancing Approaches

Solution	What It Provides	What Still Needs to Be Added
HAProxy or NGINX	Load balancing, basic health checks, and traffic distribution.	WAF, centralized certificate management, rate limiting, high availability for the load balancer itself, and unified observability.
Native Cloud Load Balancer	Fast deployment within a specific cloud provider.	Portability outside that cloud platform. Advanced security features are often sold as additional managed services.
SKUDONET Enterprise Edition	Load balancing, TLS, WAF, rate limiting, high availability for the ADC itself, and centralized visibility in a single platform. Deployable as a virtual appliance, hardware appliance, bare metal installation, or cloud instance.	The appliance still needs to be sized and deployed within the chosen infrastructure.
SkudoCloud	The same feature set—load balancing, TLS, WAF, high availability, and observability—delivered as a SaaS platform with instant provisioning and no installation required.	Less direct control over the underlying infrastructure, since it is a fully managed service.

For organizations with the time, expertise, and resources to maintain every component separately, HAProxy and NGINX remain excellent technical foundations.

For teams that need Moodle’s availability and security to work without turning infrastructure into an ongoing integration project, SKUDONET delivers the same capabilities as a single platform: Enterprise Edition for organizations that prefer full control over where and how the solution is deployed, or SkudoCloud for those who would rather not deploy any infrastructure at all.

SKUDONET Deployment Options for Moodle

Virtual Appliance: Deploy on VMware, Hyper-V, Proxmox, KVM, or any other supported hypervisor.
Hardware Appliance: Designed for universities, public-sector organizations, and training centers that require dedicated physical infrastructure.
Bare Metal: Install the ADC directly on existing hardware.
Cloud Instance: Ideal for Moodle deployments running in public cloud or hybrid environments.
SkudoCloud: SKUDONET’s SaaS platform. Instant provisioning with no installation or long-term commitment required, including Layer 4/Layer 7 load balancing, an integrated WAF, and automatic TLS certificate management from day one. It’s the fastest way to place a highly available, secure application delivery layer in front of an existing Moodle deployment without deploying or maintaining your own appliance.

Load balancing Moodle isn’t simply about distributing traffic, it’s about designing the entire architecture for resilience.

User sessions, the database, shared storage, and security all need to be addressed together. Otherwise, the availability gained at the web layer can easily be lost elsewhere in the stack.

Building that architecture with separate tools is entirely possible, but it also means operating and maintaining multiple independent components.

An ADC with an integrated WAF doesn’t eliminate those architectural decisions, but it does consolidate them into a single platform that needs to be managed instead of five different ones.

Frequently Asked Questions

What Is Load Balancing in Moodle?

Load balancing distributes user requests across multiple Moodle web servers. It prevents a single server from becoming overloaded, eliminates the web layer as a single point of failure, and allows maintenance to be performed without disrupting access to courses, exams, or learning resources.

Does Moodle Support Load Balancing Natively?

Yes. Moodle supports deployments with multiple load-balanced web servers connected to a shared database, shared storage, and shared session store. Moodle’s official documentation describes architectures that include multiple web servers, clustered databases, and shared file storage.

What Are the Best Load Balancing Solutions for Moodle?

The answer depends on how much of the infrastructure your team wants to manage.

HAProxy and NGINX provide reliable traffic distribution but leave WAF protection, certificate management, and high availability for the load balancer itself to be implemented separately.

SKUDONET integrates all three capabilities into a single platform, available as Enterprise Edition for organizations that prefer to deploy it within their own infrastructure, or as SkudoCloud for those looking for an instantly provisioned SaaS solution.

Which Companies Offer Scalable Moodle Hosting with Built-In Load Balancing?

It’s important to distinguish between two different types of providers.

Some vendors manage the entire Moodle environment, including application hosting. Others—such as SKUDONET—do not host Moodle itself, but instead provide the load balancing, availability, and security layer that sits in front of an existing Moodle deployment, whether it’s running on-premises, in the cloud, or in a hybrid environment.

Where Can I Find Managed Load Balancing Services for Moodle Hosting?

SkudoCloud, SKUDONET’s SaaS platform, provides application load balancing and security with instant provisioning for existing Moodle deployments.

It doesn’t replace your Moodle hosting provider. Instead, it sits in front of your infrastructure, managing high availability, TLS termination, and WAF protection without requiring your team to deploy or operate that layer themselves.

When Should an Organization Load Balance Moodle?

Organizations should consider load balancing Moodle whenever the platform supports mission-critical education or training services, experiences significant traffic spikes, requires maintenance without downtime, or has reached the point where relying on a single web server represents an unacceptable availability risk.

Deepin: Linyaps Store V3.5: Full Flutter Rewrite with Zero-CLI Automated Environment Configuration

guoxinzhu — 2026-07-27T09:15:35+00:00

Summary: Linyaps — an open-source, containerized package management toolkit that isolates applications from the host OS to eliminate dependency conflicts — today released version 3.5 of its desktop store client. The new edition completes a full architectural shift from Tauri to Flutter, delivering pixel-perfect UI consistency across AMD64, ARM64, and the emerging LoongArch (Loong64) architecture. It also introduces a one-click environment initializer and shareable app installation links, directly addressing two long-standing pain points in Linux software deployment. Full Flutter Migration: Why It Matters Linyaps Store v3.5 fully rebuilds the client stack on Flutter Desktop, resolving long-standing cross-platform inconsistencies present in ...Read more

SparkyLinux: Fooyin

pavroo — 2026-07-26T09:18:29+00:00

There is a new application available for Sparkers: Fooyin What is Fooyin? Features: – Support for major formats including FLAC, MP3, MP4, Vorbis, Opus, WavPack, WAV, AIFF, MKA, Musepack, and Monkey’s Audio – Native support for VGM and tracker/module formats through optional plugins – Playback of files directly from archives – Internet radio discovery and remote audio stream playback …

Source

Deepin: (中文) 独立开发者自制 PDF 批量打印工具，已上架应用商店！

xiaofei — 2026-07-24T02:00:25+00:00

Sorry, this entry is only available in 中文.

GreenboneOS: CVE-2026-53359 (aka Januscape): VM Escape Hits Linux KVM/x86

Joseph Lee — 2026-07-23T14:59:13+00:00

Januscape, tracked as CVE-2026-53359 (CVSS 8.8), is a use-after-free vulnerability [CWE-825] in the Linux kernel KVM/x86 that can let a guest crash its host and potentially break guest-host isolation. The highest-risk targets are Intel and AMD x86_64 KVM hosts that expose nested virtualization, especially in environments that accept untrusted guests or allow users to create […]

Purism PureOS: A STEP ahead for customization with the Librem 16

Jonathon Hall — 2026-07-23T13:46:11+00:00

Today, Purism is proud to release CAD models for the Librem 16 in both the widely used STEP and FreeCAD formats. Under the terms of the Creative Commons BY-SA 4.0 license, you are free to reproduce, modify, and integrate these components as you like, including commercially.

The post A STEP ahead for customization with the Librem 16 appeared first on Purism.

Deepin: Linyaps Store V3.5: Full Flutter Rewrite with Zero-CLI Automated Environment Configuration

xiaofei — 2026-07-23T11:29:22+00:00

Tails: Tails 7.10

Tails — 2026-07-23T00:00:00+00:00

New features

New shutdown procedure

Tails now uses the standard shutdown procedure from GNOME.

The standard shutdown procedure is a bit slower, but better prevents data loss.

For example, the Power Off confirmation dialog informs you if an application needs to be closed or an open document needs to be saved before shutting down.

Even without confirming or saving the open documents, Tails will shut down after 60 seconds.

You can still use the faster emergency shutdown as before.

Celluloid video player

We replaced GNOME Videos with Celluloid, a more modern and reliable video player.

For added security, Celluloid cannot access the network. You can either:

Open online videos, like MP4 and AVI files, in Tor Browser.
Open online streaming addresses, like IPTV and HLS addresses, in VLC, installed as additional software.

Celluloid doesn't work on some computers from 2011 or earlier.

You can use VLC instead, installed as additional software.

Changes and updates

Update Tor Browser to 15.0.19.
Update some firmware packages. This improves support for newer hardware: graphics, Wi-Fi, and so on.

For more details, read our changelog.

Get Tails 7.10

To upgrade your Tails USB stick and keep your Persistent Storage

Automatic upgrades are available from Tails 7.0 or later to 7.10.
If you cannot do an automatic upgrade or if Tails fails to start after an automatic upgrade, please try to do a manual upgrade.

To install Tails 7.10 on a new USB stick

Follow our installation instructions.

The Persistent Storage on the USB stick will be lost if you install instead of upgrading.

To download only

If you don't need installation or upgrade instructions, you can download Tails 7.10 directly:

Qubes: Qubes OS Summit 2026: Tickets for sale and speaker proposals now open!

Qubes — 2026-07-23T00:00:00+00:00

Qubes OS Summit 2026 is a three-day gathering of security enthusiasts, open-source developers, and digital privacy experts.

When and where

Friday, October 30 @ 9:30 AM — Sunday, November 1 @ 3:00 PM (GMT+1)
(A more specific schedule will be published after the speaker lineup is finalized.)

Refugio Berlin
Lenaustraße 3-4
12047 Berlin
View on OpenStreetMap

Attend in person or online

There are three ways to attend the Summit:

In person at Refugio Berlin
- Requires a paid on-site ticket
- Grants access to the hackathon (including interactive workshops) and any design sessions (depending on conference schedule)
- Provides the opportunity to socialize, network, and mingle with like-minded individuals who are passionate about secure computing
- Grants exclusive access to any non-livestreamed, non-recorded presentations (see below)
- Grants access to attend presentations and participate as a live audience member
Actively participate online
- Requires a free virtual ticket
- For those who are presenting remotely
- For those who are attending presentations remotely and wish to ask questions or engage in active discussion in a live chat during the presentations
- Does not grant access to the hackathon or any design sessions
- Does not provide the opportunity to socialize, network, or mingle with like-minded individuals who are passionate about secure computing
- Does not grant access to any non-livestreamed, non-recorded presentations (see below)
- Does not grant access to attend presentations as a live audience member
Passively view online
- No ticket or registration required
- For those who simply wish to watch the presentations via the public livestream and recorded videos
- Does not provide the ability to ask questions or engage in active discussion during the presentations
- Does not grant access to the hackathon or any design sessions
- Does not provide the opportunity to socialize, network, or mingle with like-minded individuals who are passionate about secure computing
- Does not grant access to any non-livestreamed, non-recorded presentations (see below)
- Does not grant access to attend presentations as a live audience member

Note: Presenters have the option to request that their presentations not be recorded. If a presenter opts out of recording, there will be a “no recording” icon next to that presentation in the conference schedule. Only on-site attendees will be able to view that presentation. It will not be livestreamed or recorded for later viewing.

Become a presenter

If you’d like to present at the Summit, please submit your proposal by 2026-08-31.

You may present either on site or virtually from anywhere in the world.
If your proposal is accepted and you wish to present in person, you’ll be issued an on-site ticket free of charge, no purchase necessary.
If you select “Don’t record this session” when submitting your proposal, your presentation will not be livestreamed or recorded. Online attendees will not be able to view it.

Conference schedule

We’re still reviewing proposals from prospective presenters, so the list of talks has not been decided yet. We’ll publish a detailed conference schedule after the speaker lineup has been finalized.

If you or your organization are interested in sponsoring Qubes OS Summit 2026 or becoming a Qubes Partner, please contact us at funding@qubes-os.org.

Code of conduct

This event is covered by the Qubes OS Project’s code of conduct.

Qubes: Fedora 44 templates available

Qubes — 2026-07-23T00:00:00+00:00

The following new Fedora 44 templates are now available for Qubes OS 4.3:

fedora-44-xfce — default Fedora template with the Xfce desktop environment
fedora-44-gnome — alternative Fedora template with the GNOME desktop environment
fedora-44-minimal — minimal template for advanced users

There are two ways to upgrade a template to a new Fedora release:

Recommended: Install a fresh template to replace an existing one. This option is simpler for less experienced users, but it won’t preserve any modifications you’ve made to your template. After you install the new template, you’ll have to redo your desired template modifications (if any) and switch everything that was set to the old template to the new template. If you choose to modify your template, you may wish to write those modifications down so that you remember what to redo on each fresh install. To see a log of package manager actions, open a terminal in the template and use the dnf history command.
Advanced: Perform an in-place upgrade of an existing Fedora template. This option will preserve any modifications you’ve made to the template, but it may be more complicated for less experienced users.

Note: No user action is required regarding the OS version in dom0 (see our note on dom0 and EOL).

Univention Corporate Server: Nubus for Kubernetes 1.21: Faster Provisioning, More Robust Health Checks, and a More User-Friendly Portal

Ingo Steuwer — 2026-07-22T11:08:09+00:00

The latest release of Nubus for Kubernetes puts operational stability front and center: The Provisioning Service now delivers changes from the directory service to downstream systems significantly faster. Many liveness and readiness probes have been reworked so that Kubernetes can assess the state of components more accurately. Additionally, the portal now prevents content from being visible before login. Rounding out the release is a comprehensive set of security updates – most notably an upgrade to Keycloak 26.7.0.

Provisioning Performance Improvements

The Provisioning Service distributes changes from the directory service as events to all connected consumers. If a consumer did not acknowledge an event – for example because it was restarting or temporarily unreachable – redelivery previously had to wait up to 30 seconds. In practice, this led to noticeable delays before downstream services saw the current state of the directory.

With Nubus 1.21, unacknowledged events are redelivered within approximately one second. After an interruption, consumers are therefore back up to date much faster. As part of these changes, the embedded NATS message broker has also been updated to version 2.14.3.

Comprehensive Security Updates for Containers and Keycloak

A major focus of this release is on security updates. Keycloak is upgraded to version 26.7.0, closing a significant number of CVEs. In addition to the version upgrade, two functional bugs in the Keycloak service were fixed that are also security-relevant:

LDAP connection was unnecessarily re-established: A regression bug caused Keycloak to open a new LDAP connection for every operation instead of reusing the existing one. Under load, this resulted in a flood of BIND requests against the LDAP server. Keycloak now binds once and continues to use the established connection. The required patch was developed by Univention and contributed upstream to the Keycloak project.
Login failures after username case changes: After changing the capitalization of a username – for example from FOO to foo – login to the portal and UMC sometimes failed with HTTP 401. The cause was that Keycloak continued to use the cached value until the internal user cache expired. The LDAP User Federation no longer caches imported users and instead reads the UID directly from the LDAP server on every login. As a result, renamed users can log in again immediately. This setting takes effect automatically with the upgrade.

Beyond that, this release includes an extensive set of errata updates for numerous libraries and components contained in the container images – including critical and high-severity CVEs in golang.org/x/crypto, golang.org/x/net, containerd, cryptography, and several Netty modules. The complete list of all resolved CVEs can be found in the release notes.

This continuous maintenance of the container base is part of the strategy to identify and close security vulnerabilities in upstream components as quickly as possible.

New and Improved Liveness and Readiness Probes

Kubernetes relies on liveness and readiness probes to decide whether a pod should receive traffic or needs to be restarted. In several Nubus for Kubernetes components, these probes previously provided limited insight.

With version 1.21, the probes for the UDM REST API containers (for API-based administration) and the UMC Server (for graphical administration) have been significantly reworked. They now also detect runtime issues within the containers, providing more reliable feedback on the health of the services.

For operators, this means: Kubernetes detects unhealthy components more reliably while cleanly distinguishing between a truly non-functional pod and a temporary disruption of a backend such as LDAP – thereby avoiding unnecessary restarts of healthy pods.

Portal: No More Content Before Enforced Login

When the Users are required to login option is enabled for a portal, anonymous visitors should only see the login page. Previously, however, the portal briefly displayed content that was available to anonymous visitors before redirecting to the login page. This affected tiles without group restrictions that are visible to all users by default and were therefore also shown to anonymous visitors.

With Nubus 1.21, this behavior is corrected: When login is enforced, anonymous visitors are redirected directly to the login page without the portal rendering or delivering categories, tiles, folders, or menu entries beforehand. For all deployments that intend to make portal content accessible exclusively to authenticated users, this update improves the end-user experience and closes a potential data exposure gap.

Bits & Pieces

In addition to the highlights above, Nubus 1.21 includes several smaller adjustments. Notably, the Guardian component, including its container images, has been temporarily removed from the Nubus umbrella chart. This step prepares for an upcoming backend change and has no impact on the behavior of existing deployments.

As always, the Release Notes contain all the details, and the installation is described in the Nubus Operations Manual.

Der Beitrag Nubus for Kubernetes 1.21: Faster Provisioning, More Robust Health Checks, and a More User-Friendly Portal erschien zuerst auf Univention.

GreenboneOS: wp2shell: Exploit Chaining for Unauthenticated RCE in WordPress

Joseph Lee — 2026-07-22T10:53:46+00:00

A WordPress Core vulnerability chain, publicly nicknamed wp2shell, combines CVE-2026-63030 (CVSS 9.8) and CVE-2026-60137 (CVSS 5.9) for pre-authentication remote code execution (RCE). The exploit chain affects WordPress 6.9.x before 6.9.5 and 7.0.x before 7.0.2. WordPress 6.8.x before 6.8.6 is affected by CVE-2026-60137 alone. Dozens of proof-of-concept (PoC) exploits have been published for the full exploit […]

GreenboneOS: TLS and SSH Security: Greenbone Has Updated Compliance Policies for the BSI’s TR-03116-4 and TR-02102-4

Greenbone AG — 2026-07-21T11:49:06+00:00

Technical guidelines published by government bodies define the highest security standards for protecting the national IT infrastructure. As the cyber security landscape becomes more perilous, it’s even more important for organizations to be diligent about implementing the strictest security standards. Government organizations need to ensure compliance, while private-sector entities can use the standards as benchmarks […]

Univention Corporate Server: More Speed for Nubus, More Predictability for UCS: Separate Maintenance Cycles for IAM and Operating Environment

Ingo Steuwer — 2026-07-21T06:38:43+00:00

With UCS 5.3, we are introducing an important structural change to our maintenance concept: We are following our product structure and splitting the previously shared maintenance commitment for the combination of Nubus as an Identity & Access Management solution (IAM) and UCS as the operating environment into two independent commitments.

What may initially sound like an internal restructuring has practical benefits for operators: more predictable updates at the operating level (UCS) and faster access to new features at the IAM level (Nubus).

In this article, we explain why we are taking this step, what specifically is changing – and what stays the same.

How Maintenance Worked with UCS Until Now

Until now, the maintenance commitment for Nubus and the underlying UCS operating environment was jointly tied to the release cycle of UCS. This meant: A shared commitment for stable, backward-compatible maintenance, with optionally long durations (LTS), covered both the IAM functionality of Nubus and the technical operating environment UCS.

Larger, potentially incompatible changes, for example new features affecting existing configurations, the switch to a new major version of an upstream component such as a new Debian version, or the deprecation of individual features, were generally tied to UCS minor or major releases.

This model was common practice for many years: Within a minor release, the environment remains stable, and larger changes are bundled and announced.

The Disadvantages of the Shared Commitment

With Nubus as an independent product that can be operated both on UCS and on Kubernetes, the limits of this tight coupling to exactly one release rhythm became apparent. The different requirements of IAM functionality and operating platform can be better represented through separate release and maintenance cycles.

Two challenges have become particularly evident in this regard:

New features had to wait for the next release: A planned change, for example a new Nubus feature or an update of an IAM component, could not be released as soon as it was ready. Instead, it had to wait for the next minor release of UCS. As a result, new features were unnecessarily delayed.

Too many changes came at once: When a minor or major release was published, it inevitably contained both changes to the operating environment (for example the Debian base or system services) and changes at the IAM level, such as the switch to Keycloak in UCS 5.2.
For operators, this meant: A single update event that simultaneously involved infrastructure testing, adjustments to connected applications, as well as coordination with various responsible parties and stakeholders.

As a result, updates became more extensive than they needed to be. In practice, this often led to rollouts taking longer, because many different tasks had to be taken into account at the same time.

What Is Changing Now

With UCS 5.3, we are splitting the maintenance commitment into two independent lines:

UCS as the operating environment receives its own maintenance commitment for the underlying distribution, system services, and operation in virtual machines or on hardware.
Nubus as the IAM solution receives its own maintenance commitment for directory service, single sign-on, portal, and the features built upon them, regardless of whether Nubus is operated under UCS or under Kubernetes.

Both commitments continue to follow the proven principle of stable, backward-compatible maintenance with optionally long durations (LTS). The change does not mean a reduction in maintenance, but rather a better alignment with the actual product structure.

Larger, potentially incompatible changes will in future be tied to the respective release cycle of each individual level, no longer automatically to one another.

Specifically, this means:

New Nubus features can be released independently of the release cycle of the UCS operating environment, without having to wait for the next minor release of UCS.
Updates to the UCS operating environment can be planned without automatically including larger changes to the IAM functionality.
Operators can manage testing effort and stakeholder involvement in a more targeted way: A UCS update primarily affects administrators and infrastructure managers. A Nubus update primarily affects application owners and teams that manage connected applications.

This makes operations overall simpler and more predictable and new features can be provided faster.

What Stays the Same

As important as this structural change is: The fundamental promise does not change.

The maintenance commitments remain comprehensive. For both UCS as the operating environment and Nubus as the IAM solution, the following continues to apply: stable, backward-compatible maintenance, optionally with long durations (LTS). We are splitting the commitment across two levels, we are not reducing it.
The scope of contracts does not change. There are no changes to our fundamental customer promise within existing subscription contracts.
Nubus remains flexible to operate. The separate maintenance commitment applies to Nubus regardless of the operating form, both for Nubus on UCS as a virtual machine and for Nubus for Kubernetes.

Schedule: UCS 5.3

The new, separate maintenance policy takes effect with the stable release of UCS 5.3.

The exact details, for example specific durations, affected components, and the precise delineation between the UCS operating environment and the Nubus level, will be discussed with interested customers and communicated in good time before the availability of UCS 5.3.

Feedback and Contact

This change is a direct result of the feedback we have received from operators and IT decision-makers regarding the previous update rhythm. If you are interested in being involved in the further discussion, please feel free to get in touch with us!

We look forward to your feedback, here, at help.univention.com, or with your contact person at Univention.

Der Beitrag More Speed for Nubus, More Predictability for UCS: Separate Maintenance Cycles for IAM and Operating Environment erschien zuerst auf Univention.

Deepin: (中文) 应用商店｜时隔三年，百度网盘Linux版迎来重磅更新！

xiaofei — 2026-07-21T02:00:36+00:00

Sorry, this entry is only available in 中文.

ARMBIAN: Github Highlights

Michael Robinson — 2026-07-20T16:56:55+00:00

This week&aposs updates center on new hardware enablement, a broad U-Boot v2026.07 modernization, and build system hardening for toolchain and infrastructure changes.

Board support expanded across multiple SoC families, including the X88 PRO RK3566 TV box, Avnet MaaXBoard 8ULP (i.MX8ULP), EASY EAI Nano (RV1126), and the AYN Odin3. The Youyeetoo R1 v3 was promoted to standard support with named audio outputs, while the Radxa Dragon Q8B gained an edge kernel (7.1) target. Rockchip work included RK3588 CAN support for kernels 6.18/7.1/7.2, HDMI-RX fixes on the OrangePi 5 Ultra, and Mixtile Blade3 refinements on the 7.2 bleeding edge.

A coordinated U-Boot bump to v2026.07 landed across Helios4, Odroid HC4/M1, Turing RK1, Radxa E52C, Qidi X6, Mekotronics R58X-Pro, and the Espressobin/Macchiatobin (paired with TF-A 2.14.0). This surfaced toolchain issues on Trixie, addressed through SWIG 4.3 pylibfdt compatibility, demotion of gcc 14 int-conversion and implicit-declaration errors to warnings, and related pin cleanups.

Infrastructure work strengthened build reliability and CI. The rootfs stage gained DNS fallback and apt retry hardening for chroot operations, armbian-firstlogin received power-loss recovery with atomic writes, and armbian-install now reports bootloader write failures explicitly. Docker framework updates enable native riscv64 image generation on trixie and noble runners, while new extensions introduce sysrq serial trigger, kernel-debug tiers, ram-boot via rkusbboot, and generic SATA park-on-shutdown enabled by default on the Odroid HC4.

#Armbian #EmbeddedLinux #UBoot #Rockchip #RISCV

Changes

Add support for X88 PRO RK3566 TV box. by @Ovaday in armbian/linux-rockchip#500
Add AI-driven README updater (central, cross-repo). by @igorpecovnik in armbian/armbian.github.io#359
Add Avnet MaaXBoard 8ULP (i.MX8ULP) support. by @govindsi in armbian/build#9991
Add AYN Odin3 firmware. by @kasimling in armbian/firmware#136
Add ayn-odin3 board image. by @kasimling in armbian/armbian.github.io#358
Add board: EASY EAI Nano RV1126. by @hqnicolas in armbian/build#10154
Add minimal SWT6621S firmware support for KICKPI K3B. by @retro98boy in armbian/firmware#134
armbian-firstlogin: power-loss recovery and atomic writes. by @mingzhangqun in armbian/build#9954
armbian-install: report bootloader write failures instead of "Done.". by @iav in armbian/build#10204
artifact-rootfs: surface git-log failure when computing configng hash. by @igorpecovnik in armbian/build#9849
board: aml-c400-plus: Fix eMMC boot format and partition layout. by @jomadeto in armbian/build#9911
boards/easy-eai-nano: enable usb and brcm wifi. by @hqnicolas in armbian/build#10177
brcm: add brcmfmac firmware aliases for easy-eai nano (rv1126). by @igorpecovnik in armbian/firmware#133
bsp: generic SATA park-on-shutdown (HDD_PARK_ON_SHUTDOWN), enable on Odroid HC4. by @igorpecovnik in armbian/build#10191
bsp: use kernel version argument in ABL postinst scripts (fixes #10108). by @rorystandley in armbian/build#10109
can: rockchip: add RK3588 CAN support (for kernel v6.18 / v7.1 / v7.2). by @lch08 in armbian/build#10184
ci(board-assets): don&apost check out fork head under pull_request_target. by @igorpecovnik in armbian/build#10194
cix-acpi: bump edge to 7.1.y. by @EvilOlaf in armbian/build#10167
Cleanup patches. by @EvilOlaf in armbian/build#10174
csc board: NORCO EMB-3531: Do not reset LTE moden. by @retro98boy in armbian/build#10222
docker/framework: build riscv64 images on native runners (trixie, noble). by @igorpecovnik in armbian/docker-armbian-build#34
docker/framework: generate riscv64 images (trixie, noble, resolute). by @igorpecovnik in armbian/docker-armbian-build#33
docker/riscv64: fix cross-compiler availability for generate-dockerfile. by @igorpecovnik in armbian/build#9589
docker: allow overriding host_arch for foreign-arch Dockerfile generation. by @igorpecovnik in armbian/build#10211
docs: refresh README (AI-assisted). by @igorpecovnik in armbian/ci#29
Enable memory compaction and RK630 PHY on Rockchip vendor kernels . by @lukaszsobala in armbian/build#10175
Enable pwm gpio. by @frank-f in armbian/build#10238
extensions/nvidia: per-distro version detection + runtime auto-disable on no-GPU hosts. by @igorpecovnik in armbian/build#9845
extensions/radxa-aic8800: use local dir as download cache. by @rpardini in armbian/build#10156
extensions/rkusbboot: easy ramboot mainline u-boot on Rockchip devices. by @rpardini in armbian/build#10158
feat(extensions): sysrq-serial-trigger + kernel-debug-tiers (on-device kernel debugging via serial console). by @iav in armbian/build#9776
feat(flash): keep the success screen when verification is cancelled. by @SuperKali in armbian/imager#166
Fix build for Linux 7.1. by @EvilOlaf in armbian/bcmdhd-dkms#7
fix hdmi rx on orangepi5 ultra by adding hpd-gpios. by @pdapandapda in armbian/build#10172
fix Radxa U-Boot ITB dependency. by @yisding in armbian/build#10196
Fix sata2 target-supply for Orange Pi 3B and Station M2. by @dust-7 in armbian/build#10137
fix the hdmirx HPD patch against kernel6.18 & kernel 7.1. by @pdapandapda in armbian/build#10180
fix(offline): honor OFFLINE_WORK in git-ref2info and memoize TTL. by @iav in armbian/build#9797
gha: disable build cronjobs (moved to armbian/ci). by @igorpecovnik in armbian/os#482
git: match safe.directory literally, not as a regex. by @igorpecovnik in armbian/build#10223
git: silence spurious SUBSHELL error annotation from safe.directory check. by @igorpecovnik in armbian/build#10225
helios4: bump u-boot to v2026.07. by @iav in armbian/build#10183
helios4: drop stale u-boot patch dir v2025.10/board_helios4. by @iav in armbian/build#10189
input: remotectl: rockchip-pwm: prefer dedicated channel-3 IRQ. by @rpardini in armbian/linux-rockchip#503
k3: sk-am62-lp: shrink R5 SPL to fit SRAM + silence k3 cp noise. by @igorpecovnik in armbian/build#10230
luckfox-lyra-ultra-w: Add spidev overlay with 2 CS. by @vidplace7 in armbian/linux-rockchip#505
mainline: bump bleedingedge to v7.2-rc3. by @EvilOlaf in armbian/build#10181
mekotronics-r58x-pro: u-boot: bump to v2026.07. by @rpardini in armbian/build#10232
mixtile-blade3: edge: u-boot: fancy it up (lwIP, mbedTLS, efi, btrfs, etc). by @rpardini in armbian/build#10234
mvebu64: modernize EspressoBin/MacchiatoBin firmware (u-boot 2026.07 + TF-A 2.14.0 + A3720 fixes). by @igorpecovnik in armbian/build#10213
odroidhc4: u-boot: bump to v2026.07, drop upstreamed patch. by @rpardini in armbian/build#10233
odroidm1: bump u-boot to v2026.07. by @iav in armbian/build#10201
Qidi X6: update to u-boot 2026.07. by @Shadowrom2020 in armbian/build#10228
radxa-dragon-q8b: add edge kernel (7.1) target. by @SuperKali in armbian/build#10215
radxa-e52c: bump uboot to v2026.07. by @okrc in armbian/build#10135
Rk3588 es8388 codec silence log. by @CT1IQI in armbian/build#10198
rockchip64-6.18: rework rk3588-0010-fix-clk-divisions to avoid patching include/linux/math.h. by @rpardini in armbian/build#10207
rockchip64-7.2: bleedingedge: enable REALTEK_PHY_HWMON. by @rpardini in armbian/build#10206
rockchip64-7.2: rk3588-mixtile-blade3, many fixes and additions. by @rpardini in armbian/build#10203
rootfs-image: move pre_install_distribution_specific inside install_distribution_specific(). by @rpardini in armbian/build#10157
rootfs: DNS fallback for build-time chroot resolv.conf. by @igorpecovnik in armbian/build#10205
rootfs: harden chroot apt against transient fetch failures (retries + fail-fast update). by @igorpecovnik in armbian/build#10202
rootfs: pin tar for resolute kernel deb install (all families). by @igorpecovnik in armbian/build#10187
rootfs: revert resolute tar pin (#10187) — fixed upstream. by @igorpecovnik in armbian/build#10209
runner-clean: drop stale amlogic FIP source caches. by @igorpecovnik in armbian/actions#28
runner-clean: ensure tree is installed on the host. by @igorpecovnik in armbian/actions#27
runner-clean: register qemu binfmt handlers on the host. by @igorpecovnik in armbian/actions#26
sc8280xp: fix wrong LINUXCONFIG name for the sc8280xp branch. by @igorpecovnik in armbian/build#10227
SpacemiT: Defconfig: Enable CONFIG_PWM_PXA. by @fkpwolf in armbian/build#10182
sun55iw3-syterkit: skip TF-A build (SyterKit is self-contained). by @igorpecovnik in armbian/build#10214
targets: drop resolute from riscv64 userspace builds (RVA23 vs RV64GC). by @igorpecovnik in armbian/ci#27
turing-rk1: bump u-boot v2024.04 → v2026.07 (fix SWIG 4.3 build break on trixie). by @igorpecovnik in armbian/build#10216
u-boot: bump 2026.07-rc4/rc5 pins to final v2026.07. by @igorpecovnik in armbian/build#10186
u-boot: don&apost error on implicit declarations (gcc ≥ 14 / trixie). by @igorpecovnik in armbian/build#10221
u-boot: fix old pylibfdt build against SWIG ≥ 4.3 (trixie). by @igorpecovnik in armbian/build#10217
u-boot: sync btrfs zstd short-extent fix into shadowed board/pool copies. by @iav in armbian/build#10208
uboot: demote int-conversion & incompatible-pointer-types to warnings (gcc 14). by @igorpecovnik in armbian/build#10224
Up rtw8822b to v30.20.0. by @farwayer in armbian/firmware#135
update Helios4 BSP postinst. by @leggewie in armbian/build#9065
workflows: add Delete Old Releases (copied from os). by @igorpecovnik in armbian/ci#26
workflows: enable build cronjobs (taking over from armbian/os). by @igorpecovnik in armbian/ci#25
youyeetoo-r1-v3: bump mainline u-boot to v2026.04. by @SuperKali in armbian/build#10219
youyeetoo-r1-v3: promote to standard support and name audio outputs. by @SuperKali in armbian/build#10220

GreenboneOS: Greenbone’s OPENVAS SCAN Now Supports the Nutanix AHV Hypervisor

Greenbone AG — 2026-07-20T12:29:33+00:00

Users appreciate when software can easily integrate into their existing IT environment. For vendors, this means supporting a cross-platform mix of operating systems and infrastructure. Greenbone is excited to expand our virtualization platform support, bringing Nutanix AHV into our family of supported hypervisors. This addition adds flexibility for deploying OPENVAS SCAN and extends Greenbone’s already […]

Deepin: (中文) 应用商店来了音视频神器——小丸工具箱Linux版上架！

xiaofei — 2026-07-17T02:30:53+00:00

Sorry, this entry is only available in 中文.

GreenboneOS: CTX696604: Multiple New Flaws Affecting Citrix NetScaler ADC and NetScaler Gateway

Joseph Lee — 2026-07-16T13:43:26+00:00

Citrix security advisory CTX696604 covers six vulnerabilities in customer-managed NetScaler ADC and NetScaler Gateway. NetScaler Gateway is used to authenticate remote users and connect them to internal network resources, and NetScaler ADC load balancing is a core feature used to distribute requests and improve availability. The highest-risk issues in the bulletin can lead to memory […]

GreenboneOS: BeyondTrust BT26-03: Critical and High-Severity Flaws in Remote Support and Privileged Remote Access

Joseph Lee — 2026-07-15T08:59:03+00:00

BeyondTrust advisory BT26-03, issued on July 6th, 2026, describes multiple new vulnerabilities in BeyondTrust Remote Support (RS) and BeyondTrust Privileged Remote Access (PRA). The vulnerabilities include two critical flaws exploitable without authentication and additional high-severity issues in network communication and web application components. All the flaws require specific configurations for exploitation, but BeyondTrust has not […]

Deepin: (中文) 多款主流 Coding Agent 组团登陆 deepin 应用商店！

xiaofei — 2026-07-15T01:43:26+00:00

Sorry, this entry is only available in 中文.

Clonezilla live: Stable Clonezilla live 3.3.3-15 Released

Steven Shiau — 2026-07-14T12:54:46+00:00

This release of Clonezilla live (3.3.3-15) includes major enhancements and bug fixes.

ENHANCEMENTS AND CHANGES SINCE 3.3.2-31

The underlying GNU/Linux operating system was upgraded. This release is based on the Debian Sid repository (as of 2026/Jul/05).
The Linux kernel was updated to 7.0.14-1.
Added package network-manager-tui in the live system. Thanks to Sammie Lee Walker.
Made the variable supp_boot_param_ocs_live_extra available to be used for netboot clients. Thanks to haifeng.
ocs-onthefly: Added Reverse-Connection Network Cloning. Thanks to Hell Gate for this suggestion.
Introduced new programs: cnvt-ocsiso-qcow2 & ocs-check-initrd-module.
Improved check_source_and_target_type in ocs-onthefly so that it can deal with multiple disks which have existing partitions.
Implemented a better way for function disable_sudo_use_pty in ocs-live-hook-functions.
Memtest86+ was updated to 8.10.

BUG FIXES

Wrong result when using ntfsclone to save a partition as Ctrl-C is pressed. Thanks to nicdai for reporting this issue.
Fixed: protected device name "ask_user" in ocs-onthefly. Ref: https://sourceforge.net/p/clonezilla/bugs/440

Qubes: XSAs released on 2026-07-14

Qubes — 2026-07-14T00:00:00+00:00

The Xen Project has released one or more Xen security advisories (XSAs). The security of Qubes OS is not affected.

XSAs that DO affect the security of Qubes OS

The following XSAs do affect the security of Qubes OS:

(none)

XSAs that DO NOT affect the security of Qubes OS

The following XSAs do not affect the security of Qubes OS, and no user action is necessary:

XSA-498: Qubes OS does not use XAPI.

About this announcement

GreenboneOS: CVE-2026-48282: CVSS 10 Flaw in Adobe ColdFusion Is Actively Exploited and More

Joseph Lee — 2026-07-13T12:55:49+00:00

CVE-2026-48282 (CVSS 10) is a critical path traversal vulnerability [CWE-22] in Adobe ColdFusion. According to Adobe’s Security Bulletin [APSB26-68], the issue affects ColdFusion 2025 Update 9 and earlier, and ColdFusion 2023 Update 20 and earlier. Exploitation is network-based, which increases the risk to exposed ColdFusion instances, and exploitation does not require authentication. A successful attack […]