August 03, 2026

hackergotchi for Volumio

Volumio

How to Build a Raspberry Pi Music Streamer

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.

03 August, 2026 09:03AM

August 01, 2026

hackergotchi for SparkyLinux

SparkyLinux

Sparky news 2026/07

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

01 August, 2026 05:25PM by pavroo

July 31, 2026

hackergotchi for Purism PureOS

Purism PureOS

PureOS Development Report: June 2026

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.

31 July, 2026 10:48PM by Purism

hackergotchi for GreenboneOS

GreenboneOS

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

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 […]

31 July, 2026 12:03PM by Greenbone AG

hackergotchi for Deepin

Deepin

July 30, 2026

hackergotchi for GreenboneOS

GreenboneOS

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

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, […]

30 July, 2026 12:08PM by Joseph Lee

hackergotchi for Univention Corporate Server

Univention Corporate Server

Introducing the Univention Integration Catalog: One Home for Every Integration

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.

30 July, 2026 08:35AM by Vanessa Knoop

July 29, 2026

hackergotchi for ARMBIAN

ARMBIAN

Armbian Newsletter July 2026

Armbian Newsletter July 2026

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.

SPONSORED
Armbian Newsletter July 2026

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

29 July, 2026 03:29PM by Michael Robinson

The factory behind Armbian

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 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:

  1. A developer updates code (kernel patches, board definitions, build scripts)
  2. A workflow starts automatically
  3. The system prepares a build environment
  4. Kernels and packages are compiled
  5. OS images are built
  6. Checks and validations are executed
  7. Results appear on actions.armbian.com
  8. 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.

29 July, 2026 03:16PM by Igor Pecovnik

Beat the heat

Why thermal management is non-negotiable for modern SBCs

Beat the heat

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

  1. 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.
  2. 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.
  3. 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.

29 July, 2026 03:13PM by Michael Robinson

hackergotchi for GreenboneOS

GreenboneOS

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

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 […]

29 July, 2026 12:31PM by Joseph Lee

July 28, 2026

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

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 […]

28 July, 2026 01:58PM by Joseph Lee

hackergotchi for Univention Corporate Server

Univention Corporate Server

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

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.

28 July, 2026 11:43AM by Ingo Steuwer

hackergotchi for VyOS

VyOS

VyOS Project June & July 2026 Update

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. 

28 July, 2026 10:45AM by Daniil Baturin (daniil@sentrium.io)

hackergotchi for Deepin

Deepin

hackergotchi for ARMBIAN

ARMBIAN

Github Highlights

Github Highlights

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


28 July, 2026 01:16AM by Michael Robinson

hackergotchi for Qubes

Qubes

XSAs released on 2026-07-28

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.

28 July, 2026 12:00AM

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

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

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEELRdx/k12ftx2sIn61lWk8hgw4GoFAmpoeyMACgkQ1lWk8hgw
4GqUjw//brO4x3oOygOpewPqcjgYqohh4qPu5Dpm6JBvtxiIZQWEv9UZg0RqfMVc
omoalUCQhoTPu8QYnXu3HKo87LGcrUKKf2KeRx4CyT8LsZCQufA25uWD3Sr6eVsA
38Q/Znq3VyUpa5tMQm28JIIA9m2PMAMaXu5ElZVAw5kvcRncwRh8WDOrkVOO97ll
gSfBo3SJ0OfSUDcQvGa8f5+4Jx/SPoJn5zLo3Ott4tT7Tz2NAfE2Xlxl7karasY/
vCY+Lo8ACN+0ShELslGKYZnNdwLuwkz3lVN+FqDbLrHauBUjDLH7+yTXJvO9ZoXq
3LTpHopzv8oSJJyhq0YeO4XlKt+USn2HbIMqhJ9ON8aHHVE3/YhVJume4RuxSlHx
WAStN0bYH/NqSywYB3wWmGEho9wRw8bxLrOBIuZO3V63HpMJnCL412F7RFA2/9iS
muq3Iix9YpqfI/Q1Q18JSnYYLlWaphMtc/OJki5FAzp1B5DtQtPcQtg/vcy9tsrX
P9zrK4j3Dj/vPzZd6DwDmTBPxuiLQX79TQojl7NClVatkULfdHQGDKogfPmsJng9
IpKMBkMZ85QVv+DG/XFtXpynBdeg/6eTeWiexC7WF3HgILkhy2RadQz0eHsEwCmp
fIeVYQ2Es3eVH7aNaPHwaAcklNP+7yppgw5O81PGOlbD3Z9a15Y=
=vPOZ
-----END PGP SIGNATURE-----

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

Simon Gaiser (aka HW42)’s PGP signature

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEE6hjn8EDEHdrv6aoPSsGN4REuFJAFAmpoh00ACgkQSsGN4REu
FJCSVhAApAdVntLjACF7SJ9h7SF4M1IiDKKUQRnUhwEa06d/qDjFg/aVlsL6LghW
+cKpPdjSDWwGPhAsJhbxTeiSSAkX300qJuqX3/K0h6iw7jaQkqb6kmwaAhK7J8Ym
9F5LvcP8Vvx3G0Gi4YogNzrwA+AMlfCgKLgp7MsHKumE1TY0pp5dI6DMqz2/EasV
ODrppsfXkMMmES5aR8C6Pxe51pfBbXVqVmffjYxaz/C9VvcfGbHja8OdnOuNeqmo
yzR2pP6BGdIl2KGfq1GzuuYWtitIcrG8aEnYfcmhiHbHkTIObNwHo7MOwBT2Q9H4
ALJfuBfC1ChBvmmzRIPgOzPbiz0MLIWcjFvKRmXW8azTTQOyRQQbG5lDGeu+aJm0
ZRdyXPQh2294MmmL3r+xtyFJTFw5WABdxjZa10nlB5B5JQ8FrV7koNc4quXhCS4U
ceAwpvCuRKTX1Lg+NDaPFtxAmYX98QkLT09V34vyqksOcMR+DY7stHol8T+hYIMM
8DXZDBdndUMkU/DU5xfj4Z/wtgkB66eLKBypxqibiPx33vkBZOIAYtNYK7zFnrTk
HnrHAGpm0sLlNdLzNA4XQ7yMTdDwzxW6GeYacYWxDT3t9Qc9vroGVju3CExQtljs
4znS5FAHrlPSv4xi7aWiypVwB/MsMbrdNcd0/g9px6RbszpNGpA=
=BjeB
-----END 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.)

  1. 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.)

  2. 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
    
  3. 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.

  4. 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
    
  5. 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.
    
  6. 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
    
  7. 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.

  8. 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.

28 July, 2026 12:00AM

July 27, 2026

hackergotchi for AIMS Desktop developers

AIMS Desktop developers

DebConf26 – Santa Fe, Argentina

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:
  • 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!

27 July, 2026 08:12PM by jonathan

hackergotchi for ZEVENET

ZEVENET

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

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

  1. Prepare identical Moodle nodes using the same version, plugins, and configuration.
  2. Configure a shared database and shared moodledata storage.
  3. Create an HTTPS virtual service using the public IP address and port that users will access.
  4. Add the Moodle servers as backend nodes for the virtual service.
  5. Configure application-level health checks rather than relying solely on open-port checks.
  6. Choose the appropriate load-balancing algorithm:
    • Round Robin for identical servers.
    • Least Connections when request duration varies.
    • Weighted when backend servers have different capacities.
  7. Enable session persistence (sticky sessions) to reduce contention in the shared session store and keep each user’s requests on the same node.
  8. 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
  9. Preserve the client’s real IP address using X-Forwarded-For, while maintaining a well-defined list of trusted proxies.
  10. 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.

Moodle-with-Skudonet

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.

27 July, 2026 12:13PM by Isabel Perez

hackergotchi for Deepin

Deepin

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

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

27 July, 2026 09:15AM by guoxinzhu

July 26, 2026

hackergotchi for SparkyLinux

SparkyLinux

Fooyin

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

26 July, 2026 09:18AM by pavroo

July 24, 2026

hackergotchi for Deepin

Deepin

July 23, 2026

hackergotchi for GreenboneOS

GreenboneOS

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

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 […]

23 July, 2026 02:59PM by Joseph Lee

hackergotchi for Purism PureOS

Purism PureOS

A STEP ahead for customization with the Librem 16

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.

23 July, 2026 01:46PM by Jonathon Hall

hackergotchi for Deepin

Deepin

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

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

23 July, 2026 11:29AM by xiaofei

hackergotchi for Tails

Tails

Tails 7.10

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:

23 July, 2026 12:00AM

hackergotchi for Qubes

Qubes

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

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:

  1. 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
  2. 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
  3. 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.

Become a sponsor

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.

23 July, 2026 12:00AM

Fedora 44 templates available

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-minimalminimal template for advanced users

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

  1. 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.

  2. 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).

23 July, 2026 12:00AM

July 22, 2026

hackergotchi for Univention Corporate Server

Univention Corporate Server

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

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.

22 July, 2026 11:08AM by Ingo Steuwer

hackergotchi for GreenboneOS

GreenboneOS

wp2shell: Exploit Chaining for Unauthenticated RCE in WordPress

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 […]

22 July, 2026 10:53AM by Joseph Lee

July 21, 2026

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

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 […]

21 July, 2026 11:49AM by Greenbone AG

hackergotchi for Univention Corporate Server

Univention Corporate Server

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

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:

  1. 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.
  1. 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.

21 July, 2026 06:38AM by Ingo Steuwer

hackergotchi for Deepin

Deepin

July 20, 2026

hackergotchi for ARMBIAN

ARMBIAN

Github Highlights

Github Highlights

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

20 July, 2026 04:56PM by Michael Robinson

hackergotchi for GreenboneOS

GreenboneOS

Greenbone’s OPENVAS SCAN Now Supports the Nutanix AHV Hypervisor

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 […]

20 July, 2026 12:29PM by Greenbone AG

July 17, 2026

hackergotchi for Deepin

Deepin

July 16, 2026

hackergotchi for GreenboneOS

GreenboneOS

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

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 […]

16 July, 2026 01:43PM by Joseph Lee

July 15, 2026

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

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 […]

15 July, 2026 08:59AM by Joseph Lee

hackergotchi for Deepin

Deepin

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

Sorry, this entry is only available in 中文.

15 July, 2026 01:43AM by xiaofei

July 14, 2026

hackergotchi for Clonezilla live

Clonezilla live

Stable Clonezilla live 3.3.3-15 Released

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

14 July, 2026 12:54PM by Steven Shiau

hackergotchi for Qubes

Qubes

XSAs released on 2026-07-14

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

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.

14 July, 2026 12:00AM

July 13, 2026

hackergotchi for GreenboneOS

GreenboneOS

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

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 […]

13 July, 2026 12:55PM by Joseph Lee

hackergotchi for ARMBIAN

ARMBIAN

Github highlights

Github highlights

This week&aposs updates center on expanded board support, Rockchip and Qualcomm platform maturation, and build system refinements.

New hardware coverage grew across multiple SoC families, with the Lubancat 5IO (RK3588), KickPi K3B, Mellow Fly C5 3D printer board, and community support for the Orange Pi Zero 3W (Allwinner A733). The Arduino UNO Q advanced to mainline 7.1 on the edge kernel and gained desktop hardware acceleration via Mesa pinned to Trixie backports, while the BeagleY-AI received ISP, IMX219, and VPAC patches. Companion fixes addressed NVMe/SD boot conflicts on the NanoPi M6, Ethernet on the BigTreeTech CB1, and AIC8800 UART Bluetooth on Orange Pi A733 hardware.

Rockchip work concentrated on the YY3588 and CM3588-NAS platforms, with device tree cleanups, a corrected HDMI-RX detect GPIO, and quieter DRM logging for dw-hdmi-qp and dw-dp bridges. Newer bl31, bl32, and DDR blobs landed for RK3576, and stale U-Boot was refreshed fleet-wide to resolve a SWIG build break. On the Qualcomm side, SC8280XP was refactored from a board to a family configuration, and the Radxa Dragon Q8B gained UFS image provisioning, QDL flashing support via the imager, and a mainline 7.1 edge target for the Q6A variant.

Build and tooling improvements included a new show-extensions CLI command, a switch from the adduser suite to useradd/groupadd during first login, non-interactive Dpkg conffile handling in chroot, and clang compatibility fixes for carried Rockchip64 patches and SpacemiT RTL8852BS builds. The mainline kernel target advanced to 7.2-rc2, and MGLRU was enabled across sunxi, sunxi64, and sun60iw2 kernel configurations.

#Armbian #EmbeddedLinux #Rockchip #Qualcomm #SBC

Changes

13 July, 2026 12:32PM by Michael Robinson

hackergotchi for Deepin

Deepin

July 11, 2026

hackergotchi for Qubes

Qubes

Last chance to take the 2026 user survey! (10-20 minutes)

As previously announced, Qubes OS User Survey 2026 will close on 2026-07-13. If you still wish to take the survey and haven’t completed it yet, please do so now.

Whether you’re a long-time Qubes user or haven’t even installed it yet, we want to hear about your experiences and about what matters to you. Help us make Qubes the best reasonably secure operating system it can be. If you’ve ever wanted to influence the development of Qubes, now is your chance. Make your voice heard!

Qubes OS User Survey 2026

This survey is fully anonymous. We do not collect any data except for the answers you provide.

11 July, 2026 12:00AM

July 09, 2026

hackergotchi for Purism PureOS

Purism PureOS

PQC Encryptor Video Demonstration

Purism installed and recorded the test-harness at two DOE/NNSA facilities traversing between Las Vegas Nevada and Albuquerque New Mexico. This is a first-known live installation of PQC Encryptors between two long-haul sites showcasing 10Gbps line-rate speeds with negligible latency and maximum throughput compared to cleartext.

The post PQC Encryptor Video Demonstration appeared first on Purism.

09 July, 2026 06:52PM by Purism

An exciting future with the Librem 16

With the recent launch of the Librem 16, I'm excited. Clearly I'm excited to share this product with you, but that's just the beginning. I'm excited for the future of technology.

The post An exciting future with the Librem 16 appeared first on Purism.

09 July, 2026 05:47PM by Jonathon Hall

hackergotchi for GreenboneOS

GreenboneOS

June 2026 Threat Report: Technical Debt Demands Visibility

The true impact that cyber security aware AI will have on the global threat landscape remains to be seen. By some reports, the CVE output for software made by major vendors is on the rise. This June 2026 threat report only scratches the surface of the major cyber security threats from this month. The month […]

09 July, 2026 01:05PM by Joseph Lee

July 08, 2026

Sovereignty was a promise. Now it’s becoming a test criterion.

On June 3, 2026, the European Commission proposed the Cloud and AI Development Act (CADA)—the centerpiece of its new Tech Sovereignty Package. At its core: a four-tier model that public contracting authorities will use in the future to assess how sovereign a cloud provider truly is—not just where the data is located, but who owns […]

08 July, 2026 09:28AM by Greenbone AG

hackergotchi for Deepin

Deepin

deepin 25.2.0 Released: Treeland Usability Improved & Doc Manager Text Search for Images

Learn more about deepin on DistroWatch: https://distrowatch.com/table.php?distribution=deepin Dear deepin Community Members, To further optimize the user experience of the deepin 25 system and enhance its stability, the deepin 25.2.0 image is now officially released. This update focuses on improving Treeland stability and usability, file management and search experience, and DDE interaction and stability. It refines multiple high-frequency usage scenarios, fixes numerous known issues, and significantly improves system smoothness and reliability.   deepin 25.2.0 Highlights at a Glance Treeland Desktop Environment Upgrade: Treeland stability and usability have been significantly improved, with over 20 fixes for stability and high-frequency interaction issues. It also ...Read more

08 July, 2026 01:33AM by xiaofei

deepin 25.2.0 Release Note

Learn more about deepin on DistroWatch: https://distrowatch.com/table.php?distribution=deepin Dear deepin Community Members, To further optimize the user experience of the deepin 25 system and enhance its stability, the deepin 25.2.0 image is now officially released. This update focuses on improving Treeland stability and usability, file management and search experience, and DDE interaction and stability. It refines multiple high-frequency usage scenarios, fixes numerous known issues, and significantly improves system smoothness and reliability. I. Feature Updates 1. Treeland Treeland stability has been significantly improved, with over 20 stability fixes, focusing on abnormal behaviors during login, logout, multitasking view, window management, focus switching, and more; ...Read more

08 July, 2026 01:20AM by xiaofei

July 07, 2026

hackergotchi for GreenboneOS

GreenboneOS

The Missing Handoff: How KIX and Greenbone Turn Vulnerability Scans Into Action

For the first time, attackers are exploiting unpatched vulnerabilities more often than they’re stealing credentials. According to Verizon’s 2026 Data Breach Investigations Report, vulnerability exploitation now accounts for 31% of breaches, ahead of credential theft at 13%. And the gap is moving in the wrong direction for defenders: the median time to fully patch a […]

07 July, 2026 06:38AM by Greenbone AG

hackergotchi for ARMBIAN

ARMBIAN

Github Highlights

Github Highlights

This week&aposs cycle emphasizes broad U-Boot modernization, new board and SoC enablement, and kernel and wireless driver consolidation.

A large-scale U-Boot bump moves sunxi 32-bit and 64-bit targets from v2024.01 to v2026.07-rc4, with follow-on updates for self-pinned H616/H618 boards (Zero2W, Zero3, Longan Pi 3H), Mixtile Edge2, NanoPi R5S (now patch-less), and the Youyeetoo YY3588 switching to mainline v2026.04. The imx6 line (UDOO, Cubox-i) was modernized to U-Boot v2026.07 with legacy 6.12, current 6.18, and edge 7.1 kernels. Related toolchain work fixes ODROID-C1, ODROID-XU4, Recore, and X96Q builds under Trixie&aposs GCC 14, and resolves errexit failures on Rockchip SPI boards.

Platform expansion introduces community support for the Allwinner A733-based Radxa Cubie A7Z and Orange Pi Zero 3W, Rockchip Graperain G3568 v2, and Anbernic RG Vita Pro and Lubancat-5IO image entries. BeagleY-AI gained USB, PCIe, ISP + IMX219, and VPAC patches on the vendor kernel, alongside GPU acceleration fixes for TI K3 targets and TI Wave5 VPU firmware. Rockchip RV1106 support was split into distinct RV1103G and RV1103B families, and new SPI/NVMe boot and Maskrom recovery paths were added.

On the kernel and driver side, sunxi received an H3/H5 DVFS RCU-stall fix, MMC/I2C PM deadlock resolution, MGLRU enablement, and LTE modem USB serial support. Meson64 gained a GPIO pinctrl cansleep series and v7.2-rc1 via bleedingedge, while SpacemiT K1 was updated to linux-7.2.y. The RTL8189ES, RTL8189FS, and RTL8192EU wireless drivers were migrated to dedicated forks with 7.2 compatibility and patch cleanup, and an RTW88 SDIO interrupt storm was addressed. User-visible improvements include swapfile creation fixes, useradd-based first-login provisioning, and video-group access to Rockchip MPP codec devices.

#Armbian #EmbeddedLinux #UBoot #Rockchip #Allwinner

Changes


07 July, 2026 04:20AM by Michael Robinson

July 06, 2026

hackergotchi for ZEVENET

ZEVENET

The Invisible Infrastructure Behind the Digital Economy: Why Application Resilience Is Now a Strategic Priority

Most digital transformation conversations still revolve around the same two topics: moving to the cloud, and adopting AI. Almost nobody talks about what’s underneath: the infrastructure that has to actually hold the weight of both.

That gap was on display at a recent Spanish technology summit, where government officials and industry executives kept circling back to the same point: the infrastructure layers that keep digital services running are becoming as strategically important as the services themselves. It’s a telling detail that even Spain (a market with strong digital momentum, ranking 7th globally in absolute terms in Stanford HAI’s AI Vibrancy Index) is having this conversation. If a country with that level of digital activity is worried about what’s underneath it, the concern clearly isn’t regional. Markets everywhere are racing to scale AI and digital services on infrastructure that, in most cases, wasn’t built to carry that load.

Strip away the policy language, and the question every infrastructure team eventually has to answer is much simpler: what happens when a critical application goes down for five minutes? Usually it’s some combination of lost revenue, a support queue that explodes, and a postmortem meeting nobody wants to be in.

The layer nobody thinks about, until it breaks

Ask someone to describe “digital infrastructure” and they’ll picture data centers, cloud regions, maybe a network diagram. Almost nobody mentions the layer that actually decides whether an application stays up under pressure: Application Delivery infrastructure.

This is the layer distributing traffic across servers, catching failures before users notice them, and standing between an application and an increasingly aggressive threat landscape. It’s the difference between an app that slows down gracefully when traffic spikes and one that simply disappears.

“High availability” used to mean something simpler

For a long time, high availability meant duplicating a server and calling it a day. That’s no longer enough, and most infrastructure teams already know it. Applications now run across hybrid environments, depend on a growing stack of APIs, and have to absorb traffic patterns that look nothing like they did five years ago. That shift demands:

  • Intelligent load balancing that adapts to real conditions, not static rules
  • Continuous health checks that catch problems before users do
  • Automated failover (not a 2 a.m. phone call to whoever’s on call)
  • Geographic traffic distribution
  • Layer 7 attack protection
  • Inspection of encrypted traffic without killing performance
  • Access policies that adjust dynamically, not once a quarter

In short: resilience today is less about how much hardware you’ve duplicated and more about how intelligently your traffic is actually managed.

The other thing infrastructure teams are tired of: vendor lock-in

There’s a second concern that comes up just as often when teams evaluate new ADC or load balancing platforms, and it has nothing to do with geopolitics: nobody wants to get boxed into a single vendor’s ecosystem. It shows up in almost every procurement conversation questions about licensing structures, “what happens if we need to scale,” whether a core feature is going to suddenly live behind a paywall as an add-on module six months after deployment.

What teams actually want is straightforward: predictable pricing, the freedom to deploy wherever makes sense (on-premise, cloud, hybrid), and a platform that integrates with what they already run instead of forcing them to rebuild around it.

Where the Application Delivery Controller (ADC) comes in

This is the layer where Application Delivery Controllers (ADCs) earn their place. A modern ADC isn’t just a load balancer with a new name, it combines intelligent traffic distribution, high availability, application acceleration, a Web Application Firewall (WAF), DDoS mitigation, SSL/TLS certificate management, API-driven automation, and observability into a single platform.

Bringing all of that into one place cuts down on architectural complexity and the number of things that can fail independently while improving both performance and security. That’s the principle our own platform is built around. SKUDONET Enterprise brings these same core capabilities together, deployable across physical, virtual, cloud, and hybrid environments, without core functionality locked behind extra modules.

Looking ahead

The conversation in the industry is shifting. It’s less about which new technology to adopt next and more about whether what’s underneath can actually hold it up. AI workloads, edge computing, distributed applications; none of it delivers on its promise if the infrastructure underneath buckles the first time it’s under real pressure.

That infrastructure will probably stay invisible to end users. It always has. But for the people on the hook when it fails, it’s the layer that matters most.

That’s not a comfortable thought, but it’s a fair question to ask about your own setup: if your application infrastructure had to absorb a sudden spike, an outage, or an attack tomorrow, how confident are you in the answer?

Find out in two minutes:

Will Your Application Hold Under Pressure? is a short technical assessment that checks how your current setup handles traffic spikes, malicious requests, and unexpected load and where the gaps are likely to show up first.

 


06 July, 2026 11:06AM by Isabel Perez

July 04, 2026

hackergotchi for Purism PureOS

Purism PureOS

Celebrating 250 Years of US Independence With $250 Off the Liberty Phone

In 1776, America didn't just reject a king - it rejected tolerance of oppressive governance, taxation without representation, and the idea that power is imposed by someone far away. The Liberty Phone channels the same rebellious spirit for our era, pushing back against Big Tech’s control through a privacy-first, user-owned approach. Use software you can understand, hardware you can shut off, and a system built to give control back to the user that operates it.

The post Celebrating 250 Years of US Independence With $250 Off the Liberty Phone appeared first on Purism.

04 July, 2026 06:48PM by Purism

hackergotchi for Maemo developers

Maemo developers

Reticulum is interesting

It all started innocently enough: sometime last summer, I ran into the blog post Start your own Internet Resiliency Club on Hacker News.

…communicate with each other across a few kilometers without any centralized infrastructure using cheap, low-power, unlicensed LoRa radios and open source Meshtastic text messaging software.

The idea of a local, infrastructure-free communications mesh sounded useful, especially as we were about to sail into the Pacific.

Meshtastic

While conflicts and natural disasters are hopefully far away, on the smaller atolls there is no cellular network. With Meshtastic we could communicate over LoRa.

Using Meshtastic on a boat

Over the hurricane season, the Meshtastic setup became quite extensive. Our boat has a Meshtastic node, plus a mast-mounted solar repeater. We both have Meshtastic cards that we carry with us. With these we can communicate with text messages over quite a long distance. And we get telemetry and alerts from the boat.

In Cartagena, Colombia we could hear the boat pretty much across the city. And since some of our buddy boats also run Meshtastic, we’ve even had conversations while offshore.

While the existing Meshtastic setup is serving us well, there is always room for improvement and new ideas.

Reticulum

Reticulum is a project that seeks to take this to a whole new level. It is a whole decentralized networking stack that allows anything from instant messaging and voice calls to full-on SSH sessions to be carried over a multitude of different interfaces. You can transport Reticulum over LoRa, Bluetooth, and also over regular TCP/IP networks. And if authorities didn’t take a dim view on encryption in ham radio, it would also work over our HF radio. With store-and-forward mechanisms it can deal with intermittent connectivity.

Because your identity is portable, your connectivity can be fluid. You can be sitting at a desk connected to a fiber backbone one moment, and walking through a field connected only to a long-range LoRa mesh the next. To the rest of the network, nothing has changed. Your friends do not need to update your contact info. The messages they send do not bounce back. The network senses the shift in the medium and reroutes the flow of data automatically.
You are no longer a stationary node in a fixed grid. You are a wanderer in a fluid medium.
- The Zen of Reticulum

As it stands now, Reticulum is still quite an early system with rudimentary and tech-heavy user interfaces. But that seems to be about to change: the Columba app for Android seems about as user-friendly as Meshtastic or something like Signal. There’s a lot of potential in that once it reaches a stable version.

Distributed development over Reticulum

In the meanwhile, there is one aspect of Reticulum we developers can benefit from immediately: Distributed development. With it, any rngit node running on Reticulum can be your “GitHub”. Git history, issue tracking, release distribution is already there.

I recently switched my various programming projects over. We have rngit running on the boat NAS, and VPS running a mirror behind more consistent connectivity. And for now I also mirror the work periodically to GitHub for backwards compatibility.

Reticulum for software

What I think is worthwhile to explore is having machines interface with Reticulum. Just like we can tell our boat to switch lights on via a Meshtastic message, we should be able to do the same with Reticulum. And maybe there should be a NomadNet “site” for the boat showing status of the various systems.

Going further, maybe boats could share chart data, depth soundings, weather information with each other over this. The promise of VDES, but built from the grassroots perspective.

And maybe things like NoFlo should be able to communicate over Reticulum? Reticulum implementations exist for multiple programming languages, but for this we’d need a JavaScript port.

There’s still a lot to study and to think about. Watch this space. Last time I noted that something is interesting, it took me to a ten year rabbit hole.

0 Add to favourites0 Bury

04 July, 2026 12:00AM by Henri Bergius (henri.bergius@iki.fi)