The FUSE feature enhancements were submitted today for the Linux 6.13 kernel as part of improving the file-system in user-space capabilities...

Docker Scout simplifies the integration with container image repositories, improving the efficiency of container image approval workflows without disrupting or replacing current processes. Positioned outside the repository’s stringent validation framework, Docker Scout serves as a proactive measure to significantly reduce the time needed for an image to gain approval. 

By shifting security checks left and integrating Docker Scout into the early stages of the development cycle, issues are identified and addressed directly on the developer’s machine.

Minimizing vulnerabilities 

This leftward shift in security accelerates the development process by keeping developers in flow, providing immediate feedback on policy violations at the point of development. As a result, images are secured and reviewed for compliance before being pushed into the continuous integration/continuous deployment (CI/CD) pipeline, reducing reliance on resource-heavy, consumption-based scans (Figure 1). By resolving issues earlier, Docker Scout minimizes the number of vulnerabilities detected during the CI/CD process, freeing up the security team to focus on higher-priority tasks.

Additionally, the Docker Scout console allows the security team to define custom security policies and manage VEX (Vulnerability Exploitability eXchange) statements. VEX is a standard that allows vendors and other parties to communicate the exploitability status of vulnerabilities, allowing for the creation of justifications for including software that has been tied to Common Vulnerabilities and Exposures (CVE).

This feature enables seamless collaboration between development and security teams, ensuring that developers are working with up-to-date compliance guidelines. The Docker Scout console can also feed critical data into existing security tooling, enriching the organization’s security posture with more comprehensive insights and enhancing overall protection (Figure 2).

How to secure image repositories

A secure container image repository provides digitally signed, OCI-compliant images that are rebuilt and rescanned nightly. These repositories are typically used in highly regulated or security-conscious environments, offering a wide range of container images, from open source software to commercial off-the-shelf (COTS) products. Each image in the repository undergoes rigorous security assessments to ensure compliance with strict security standards before being deployed in restricted or sensitive environments.

Key components of the repository include a hardened source code repository and an OCI-compliant registry (Figure 3). All images are continuously scanned for vulnerabilities, stored secrets, problematic code, and compliance with various standards. Each image is assigned a score upon rebuild, determining its compliance and suitability for use. Scanning reports and justifications for any potential issues are typically handled using the VEX format.

Why use a hardened image repository?

A hardened image repository mitigates the security risks associated with deploying containers in sensitive or mission-critical environments. Traditional software deployment can expose organizations to vulnerabilities and misconfigurations that attackers can exploit. By enforcing a strict set of requirements for container images, the hardened image repository ensures that images meet the necessary security standards before deployment. Rebuilding and rescanning each image daily allows for continuous monitoring of new vulnerabilities and emerging attack vectors.

Using pre-vetted images from a hardened repository also streamlines the development process, reducing the load on development teams and enabling faster, safer deployment.

In addition to addressing security risks, the repository also ensures software supply chain security by incorporating software bills of materials (SBOMs) with each image. The SBOM of a container image can provide an inventory of all the components that were used to build the image, including operating system packages, application specific dependencies with its versions, and license information. By maintaining a robust vetting process, the repository guarantees that all software components are traceable, verifiable, and tamper-free — essential for ensuring the integrity and reliability of deployed software.

Who uses a hardened image repository?

The main users of a hardened container image repository include internal developers responsible for creating applications, developers working on utility images, and those responsible for building base images for other containerized applications. Note that the titles for these roles can vary by organization.

• Application developers use the repository to ensure that the images their applications are built upon meet the required security and compliance standards.
• DevOps engineers are responsible for building and maintaining the utility images that support various internal operations within the organization.
• Platform developers create and maintain secure base images that other teams can use as a foundation for their containerized applications.

Daily builds

One challenge with using a hardened image repository is the time needed to approve images. Daily rebuilds are conducted to assess each image for vulnerabilities and policy violations, but issues can emerge, requiring developers to make repeated passes through the pipeline. Because rebuilds are typically done at night, this process can result in delays for development teams, as they must wait for the next rebuild cycle to resolve issues.

Enter Docker Scout

Integrating Docker Scout into the pre-submission phase can reduce the number of issues that enter the pipeline. This proactive approach helps speed up the submission and acceptance process, allowing development teams to catch issues before the nightly scans. 

Vulnerability detection and management

• Requirement: Images must be free of known vulnerabilities at the time of submission to avoid delays in acceptance.
• Docker Scout contribution:
  • Early detection: Docker Scout can scan Docker images during development to detect vulnerabilities early, allowing developers to resolve issues before submission.
  • Continuous analysis: Docker Scout continually reviews uploaded SBOMs, providing early warnings for new critical CVEs and ensuring issues are addressed outside of the nightly rebuild process.
  • Justification handling: Docker Scout supports VEX for handling exceptions. This can streamline the justification process, enabling developers to submit justifications for potential vulnerabilities more easily.

Security best practices and configuration management

• Requirement: Images must follow security best practices and configuration guidelines, such as using secure base images and minimizing the attack surface.
• Docker Scout contribution:
  • Security posture enhancement: Docker Scout allows teams to set policies that align with repository guidelines, checking for policy violations such as disallowed software or unapproved base images.

Compliance with dependency management

• Requirement: All dependencies must be declared, and internet access during the build process is usually prohibited.
• Docker Scout contribution:
  • Dependency scanning: Docker Scout identifies outdated or vulnerable libraries included in the image.
  • Automated reports: Docker Scout generates security reports for each dependency, which can be used to cross-check the repository’s own scanning results.

Documentation and provenance

• Requirement: Images must include detailed documentation on their build process, dependencies, and configurations for auditing purposes.
• Docker Scout contribution:
  • Documentation support: Docker Scout contributes to security documentation by providing data on the scanned image, which can be used as part of the official documentation submitted with the image.

Continuous compliance

• Requirement: Even after an image is accepted into the repository, it must remain compliant with new security standards and vulnerability disclosures.
• Docker Scout contribution:
  • Ongoing monitoring: Docker Scout continuously monitors images, identifying new vulnerabilities as they emerge, ensuring that images in the repository remain compliant with security policies.

By utilizing Docker Scout in these areas, developers can ensure their images meet the repository’s rigorous standards, thereby reducing the time and effort required for submission and review. This approach helps align development practices with organizational security objectives, enabling faster deployment of secure, compliant containers.

Integrating Docker Scout into the CI/CD pipeline

Integrating Docker Scout into an organization’s CI/CD pipeline can enhance image security from the development phase through to deployment. By incorporating Docker Scout into the CI/CD process, the organization can automate vulnerability scanning and policy checks before images are pushed into production, significantly reducing the risk of deploying insecure or non-compliant images.

• Integration with build pipelines: During the build stage of the CI/CD pipeline, Docker Scout can be configured to automatically scan Docker images for vulnerabilities and adherence to security policies. The integration would typically involve adding a Docker Scout scan as a step in the build job, for example through a GitHub action. If Docker Scout detects any issues such as outdated dependencies, vulnerabilities, or policy violations, the build can be halted, and feedback is provided to developers immediately. This early detection helps resolve issues long before images are pushed to the hardened image repository.
• Validation in the deployment pipeline: As images move from development to production, Docker Scout can be used to perform final validation checks. This step ensures that any security issues that might have arisen since the initial build have been addressed and that the image is compliant with the latest security policies. The deployment process can be gated based on Docker Scout’s reports, preventing insecure images from being deployed. Additionally, Docker Scout’s continuous analysis of SBOMs means that even after deployment, images can be monitored for new vulnerabilities or compliance issues, providing ongoing protection throughout the image lifecycle.

By embedding Docker Scout directly into the CI/CD pipeline (Figure 1), the organization can maintain a proactive approach to security, shifting left in the development process while ensuring that each image deployed is safe, compliant, and up-to-date.

Defense in depth and Docker Scout’s role

In any organization that values security, adopting a defense-in-depth strategy is essential. Defense in depth is a multi-layered approach to security, ensuring that if one layer of defense is compromised, additional safeguards are in place to prevent or mitigate the impact. This strategy is especially important in environments that handle sensitive data or mission-critical operations, where even a single vulnerability can have significant consequences.

Docker Scout plays a vital role in this defense-in-depth strategy by providing a proactive layer of security during the development process. Rather than relying solely on post-submission scans or production monitoring, Docker Scout integrates directly into the development and CI/CD workflows (Figure 2), allowing teams to catch and resolve security issues early. This early detection prevents issues from escalating into more significant risks later in the pipeline, reducing the burden on the SecOps team and speeding up the deployment process.

Furthermore, Docker Scout’s continuous monitoring capabilities mean that images are not only secure at the time of deployment but remain compliant with evolving security standards and new vulnerabilities that may arise after deployment. This ongoing vigilance forms a crucial layer in a defense-in-depth approach, ensuring that security is maintained throughout the entire lifecycle of the container image.

By integrating Docker Scout into the organization’s security processes, teams can build a more resilient, secure, and compliant software environment, ensuring that security is deeply embedded at every stage from development to deployment and beyond.

Learn more

• Get started with Docker Scout.
• Find a Docker plan that’s right for you.
• Subscribe to the Docker Newsletter. 
• Get the latest release of Docker Desktop.
• Have questions? The Docker community is here to help.
• New to Docker? Get started.

Huawei engineer Zhang Yi posted a set of nine patches today for enabling large folio support for regular files with the EXT4 file-system. These patches enable large folios for EXT4 on regular files except when using FSVERITY, FSCRYPT, or the journaled data mode. Long story short, these large folio patches can deliver some nice performance gains for both reads and writes...

openmediavault 7.4.14

• Add rudimentary support for the obsolete file systems reiserfs and reiser4. The userland apps must be installed manually via the Debian packages reiserfsprogs and reiser4progs.
• Issue #1859: Fix a problem when disabling the user home directory.
• Issue #1862: Use LC_ALL environment variable instead of LANG.

openmediavault-bcache 7.0

• Initial release

openmediavault-diskstats 7.0.2

• Issue #1862: Use LC_ALL environment variable instead of LANG.

openmediavault-k8s 7.4.2

• Use K3S v1.31.2+k3s1 by default. Existing installations won’t be upgraded automatically. To force an upgrade, create the file /var/lib/openmediavault/upgrade_k3s and run omv-salt deploy run k3s.
• Fix Traefik port configuration issue.
• Issue #1862: Use LC_ALL environment variable instead of LANG.

openmediavault-md 7.0.3

• Issue #1862: Use LC_ALL environment variable instead of LANG.

openmediavault-onedrive 7.1.3

• View log messages under Diagnostics | System Logs | Logs.

The post New updates available first appeared on openmediavault.

Inventive, open-source, and cost-effective – these words perfectly describe CapibaraZero, a multifunctional security and hacking tool developed by young innovator Andrea Canale.

Inspired by the popular Flipper Zero, a portable device used to interact with digital systems, Canale sought to create a more accessible, Arduino-based alternative. 

The original Flipper Zero, known for its ability to read, copy, and emulate RFID tags, NFCs, and even remote control signals, has become a valuable tool for tech enthusiasts. Canale’s CapibaraZero captures much of this functionality but adds his own unique approach and vision.

A student’s vision for an accessible, open-source alternative

A passionate student from the University of Turin, Canale began working on CapibaraZero while still in high school, driven by the desire to build a tool that didn’t just replicate Flipper Zero’s capabilities but improved upon them through the power of open-source design. 

CapibaraZero, named after Canale’s favorite animal, combines an Arduino Nano ESP32 with custom-designed PCB boards, making it adaptable and expandable. With sections dedicated to Wi-Fi^®, Bluetooth^®, infrared, NFC, and even network attacks, CapibaraZero allows users to experiment with multiple forms of wireless communication and digital security protocols in a way that’s affordable and accessible.

A tool for experimentation and learning

What makes CapibaraZero remarkable is not only its functionality but also Canale’s dedication to ensuring it remains open-source, user-friendly, and continually evolving. With additional modules for advanced features like Sub-GHz communication and network attacks (such as ARP poisoning and DHCP starvation), CapibaraZero empowers enthusiasts to expand the tool’s potential beyond traditional hacking devices. 

Canale has even provided an in-depth tutorial for anyone interested in building or exploring CapibaraZero on Arduino’s Project Hub. He also is sharing the project on a dedicated website and public GitHub repository. Check out the details and join Canale’s journey to push the boundaries of DIY security tools!

The post CapibaraZero: a student’s journey in reinventing hacking tools with Arduino appeared first on Arduino Blog.

Sent out last night for the ongoing Linux 6.13 merge window were all of the perf tool changes for the wonderful "perf" subsystem for performance profiling and the like. In addition to adding the HWMON PMU to "perf stat", leader sampling for inherited task events, and various other tooling improvements, there are also vendor event updates. Most notable with the updated CPU vendor events are new AMD Zen 5 processor events...

Complementing the Raspberry Pi Pico 2 that launched this summer, the Raspberry Pi Pico 2 W was announced today for $7 as the wireless-enabled variant of this small microcontroller board...

Richard Hughes of Red Hat has released Fwupd 2.0.2 as the newest update to this open-source firmware updating solution for Linux systems...

Last month we noted the Intel Processor N150, Processor N250, and Core i3-N355 Alder Lake-N Refresh CPUs were found in the upcoming ASUS NUC 14 Essential mini PC family, but availability was unclear. The Beelink EQ14 is the first Intel N150 mini PC which can be purchased today on either AliExpress (with EU plug) or Amazon for $182 and up for Black Friday and Cyber Monday 2024. Beelink calls the CPU family “Twin Lake” instead of “Alder Lake-N Refresh”, but we can’t confirm that since the N150 has not been officially launched yet and it’s not listed on Intel Ark. The computer is equipped with 16GB DDR4 memory, a 512GB NVMe SSD, two HDMI ports, two gigabit Ethernet ports, WiFi 6, etc… It also comes with a more unusual feature: a built-in AC power supply, something we previously saw in the Beelink EQ13 with an Intel N200/N100 CPU. Beelink EQ14 [...]

The post Beelink EQ14 mini PC features Intel N150 quad-core “Twin Lake” processor, built-in power supply appeared first on CNX Software - Embedded Systems News.

Bedtime stories made up on the spot

Servers operated by Flux — true privacy and decentralization for all users

Published: Nov 25, 2024

• Welcome, Flux — the new servers in v6.2-beta.1!
• What's the problem?
• Using two operators improves connection privacy.
• SimpleX decentralization compared with Matrix, Session and Tor.
• What's next for SimpleX network decentralization?

Welcome, Flux – the new servers in v6.2-beta.1!

Flux is a decentralized cloud infrastructure that consists of user-operated nodes [1]. With this beta release all SimpleX Chat users can use pre-configured Flux servers to improve metadata privacy and decentralization.

We are very grateful to Daniel Keller, CEO and co-founder of Flux, for supporting SimpleX network, and betting on our vision of extreme decentralization of communication. Flux investing their infrastructure in our vision is a game changer for us and our users.

Download new mobile and desktop SimpleX apps from TestFlight (iOS), Play Store, our F-Droid repo or GitHub.

Read on to learn why it is important and how using several operators improves metadata privacy.

What's the problem?

SimpleX network is fully decentralized, without any central component or bootstrap nodes — you could use your own servers from day one. While there is no full list of SimpleX network servers, we see many hundreds of servers in public groups.

But a large number of SimpleX app users use the servers pre-configured in the app. Even though the app randomly chooses 4 servers in each connection to improve privacy and security, prior to v6.2 for these users the servers were operated by the same company — ourselves.

Our open-source code that we are legally bound to use doesn't provide any metadata that could be used to learn who connects to whom. But the privacy of users' connections still depends on us honouring our promises and privacy policy. Flux servers in the app improve that.

Using two operators improves connection privacy

To ensure that the users' metadata from different servers cannot be combined to discover who talks to whom, the servers in each connection have to be operated by different independent organizations.

Before this version the app was choosing servers randomly. Now, when both SimpleX Chat and Flux servers are enabled it will always choose servers of different operators in each connection to receive messages and for private message routing, increasing metadata privacy for all users.

Flux servers are configured as opt-in, and the privacy policy and conditions of use that apply to Flux servers are the same as for SimpleX Chat servers, to make it simple for the users.

To improve connection privacy by using Flux servers all you have to do is to enable Flux once the app offers it, or later, via Network & servers settings, and accept that the same conditions apply.

By default, if both Flux and SimpleX servers are enabled in this version, you will be using SimpleX Chat servers to receive messages, Flux servers to forward messages to SimpleX Chat servers, and the servers of both to forward messages to unknown servers. We will enable Flux to receive messages by default a bit later, or you can change it now via settings.

Any additional servers you add to app configuration are treated as belonging to another operator, so they will also be used to improve connection privacy, together with pre-configured servers, unless you disable them.

SimpleX decentralization compared with Matrix, Session and Tor

SimpleX network decentralization model is different from other decentralized networks in several important aspects.

Communication network	SimpleX	Matrix	Session	Tor-based
Full decentralization	✅	-	-	-
No user profile identity	✅	-	-	-
Connection privacy	✅	-	✅	✅
Server operator transparency	✅	✅	-	-

Full decentralization

Fully decentralized networks do not have a central component, bootstrap nodes or any global shared state, like in cryptocurrency/blockchain-based communication networks. The presence of any central component or shared state introduces an attack vector that undermines privacy and security of the network.

No user profile identity

User profile identities, even if it is only a random number or a long-term key, undermine privacy of users connections, because in some cases they may allow network operators, observers and users to find out who talks to whom.

Most communication networks rely on fixed user profile identities. It includes Matrix and communication networks with onion routing.

SimpleX network design avoids the need for profile identities or keys, while still allowing optional long-term addresses for users and groups for convenience. It protects users from being discovered and approached by malicious parties, and many family users chose to use SimpleX with children because of it.

Connection privacy

SimpleX network has private message routing (2-hop onion routing) — it prevents server operators from discovering who connects to whom via network traffic metadata. Onion routing used in Tor-based messengers and in Session also hides it. But because neither Tor nor Session users have knowledge about who operates servers, in some cases the clients may connect via the servers controlled by one entity, that may learn the IP addresses of both parties.

Statistically, if traffic metadata from 2% of onion network servers is available to an attacker, and the client chooses servers randomly, after about 1750 of such choices the probability of choosing attacker's servers as both entry and exit nodes, and connection privacy being compromised becomes over 50% [2].

Matrix network does not provide connection privacy, as not only user identity exists, it is tied to a specific server that knows all user connections and a part of user's contacts connections. What is worse, Element — the most widely used Matrix app — offers the servers of only one organization to create an account, resulting in some degree of network centralization.

Server operator transparency

Operator transparency means that network users know who operates the servers they use.

You may argue that when the operators are known, the servers data can be requested by the authorities. But such requests, in particular when multiple operators are used by all users, will follow a due legal process, and will not result in compromising the privacy of all users.

With Tor and Session networks such legal process becomes impossible, and some users may see it as advantage. But nothing prevents the attackers, both criminal and corporate- or state-funded, to compromise the privacy of Tor or Session users by running many servers, or by purchasing traffic metadata from the existing server owners — there are no legal conditions that prohibit server owners of these networks to share or sell traffic data.

Because of that, we see operator transparency in SimpleX network as a better trade-off for privacy of most users than operator anonymity provided by Session and Tor. You can see privacy of network participants as a zero sum game — for the end users to have it, server operators should be known.

What's next for SimpleX network decentralization

SimpleX network is designed for extreme decentralization — not only users are distributed across network operators, as happens with federated networks, but each conversation will be relying on servers of 4-6 independent operators, and these operators will be regularly and automatically changed in the near future.

We believe that the only viable commercial model is freemium — a small share of paying users, who have better service quality and additional features, sponsors free users. This model doesn't have downsides of exploitative "provide service, sell data" approaches, that technology monopolies practice, and it also doesn't have problems of cryptocurrency blockchains, that have shared and immutable state, and also have regulatory problems.

To provide this extreme decentralization with freemium model we will create the system of payments allowing server operators to receive money for infrastructure certificates that will be used with any other participating network operators without compromising privacy of the paying users. You can read about this model here. We will be writing more about it as this development progresses.

SimpleX network

Some links to answer the most common questions:

How can SimpleX deliver messages without user identifiers.

What are the risks to have identifiers assigned to the users.

Technical details and limitations.

Frequently asked questions.

Please also see our website.

Please support us with your donations

Huge thank you to everybody who donated to SimpleX Chat!

Prioritizing users privacy and security, and also raising the investment, would have been impossible without your support and donations.

Also, funding the work to transition the protocols to non-profit governance model would not have been possible without the donations we received from the users.

Our pledge to our users is that SimpleX protocols are and will remain open, and in public domain, so anybody can build the future implementations of the clients and the servers. We are building SimpleX platform based on the same principles as email and web, but much more private and secure.

Your donations help us raise more funds — any amount, even the price of the cup of coffee, makes a big difference for us.

See this section for the ways to donate.

Thank you,

Evgeny

SimpleX Chat founder

[1] You can also to self-host your own SimpleX servers on Flux decentralized cloud.

[2] The probability of connection being de-anonymized and the number of random server choices follow this equation: (1 - s ^ 2) ^ n = 1 - p, where s is the share of attacker-controlled servers in the network, n is the number of random choices of entry and exit nodes for the circuit, and p is the probability of both entry and exit nodes, and the connection privacy being compromised. Substituting 0.02 (2%) for s, 0.5 (50%) for p, and solving this equation for n we obtain that 1733 random circuits have 50% probability of privacy being compromised.

Also see this presentation about Tor, specifically the approximate calculations on page 76, and also Tor project post about the changes that made attack on hidden service anonymity harder, but still viable in case the it is used for a long time.

Today, our epic autumn of product launches continues with Raspberry Pi Pico 2 W, the wireless-enabled variant of this summer’s Pico 2. Built around our brand new RP2350 microcontroller, featuring the tried and tested wireless modem from the original Pico W, and priced at just $7, it’s the perfect centrepiece for your connected Internet of Things projects.

RP2350: the connoisseur’s microcontroller, redux

When we launched our debut microcontroller, RP2040, way back in 2021, we couldn’t have imagined the incredible range of products that would be built around it, or the uses that the community would put them to. Combining a symmetric pair of fast integer cores; a large, banked, on-chip memory; rich support for high-level languages; and our patented programmable I/O (PIO) subsystem, it quickly became the go-to device for enthusiasts and professional engineers seeking high-performance, deterministic interfacing at a low price point.

RP2350 builds on this legacy, offering faster cores, more memory, floating point support, on-chip OTP, optimised power consumption, and a rich security model built around Arm’s TrustZone for Cortex-M. It debuted in August on Pico 2, on the DEF CON 32 badge (designed by our friends at Entropic Engineering, with firmware and a gonzo sidewalk badge presentation by the redoubtable Dmitry Grinberg), and on a wide variety of development boards and other products from our early-access partners.

Wireless things

Many of the projects and products that people build on top of our platforms — whether that’s our Linux-capable Raspberry Pi computers, our microcontroller boards, or our silicon products — answer to the general description “Internet of Things”. They combine local compute, storage, and interfacing to the real world with connectivity back to the cloud.

Raspberry Pi Pico 2 W brings all the power of RP2350 to these IoT projects. The on-board CYW43439 modem from our friends at Infineon provides 2.4GHz 802.11n wireless LAN and Bluetooth 5.2 connectivity, and is supported by C and MicroPython libraries. Enthusiasts benefit from the breadboard-friendly Pico form factor, while our upcoming RM2 radio module (already in use on Pimoroni’s Pico Plus 2 W) provides a route to scale for professional products which have been prototyped on the platform.

More to come

We’re very pleased with how Pico 2 W has turned out. And, where the Pico 1 series ended with Pico W, we have a few more ideas in mind for the Pico 2 series. Keep an eye out for more news in early 2025.

The post Raspberry Pi Pico 2 W on sale now at $7 appeared first on Raspberry Pi.

As expected, the Raspberry Pi Pico 2 W – the wireless version of the Raspberry Pi Pico 2 – is now available with an extra 2.4GHz WiFi 4 and Bluetooth 5.2 wireless module at an official price of $7. We’ll go through the specs and perform a mini review in this post trying out both WiFi and Bluetooth code samples. It’s not the first Raspberry Pi RP2350 with WiFi and Bluetooth we’ve seen, as Pimoroni introduced the Pico Plus 2 W board with an RP2350B MCU and Raspberry Pi RM2 Wi-Fi and Bluetooth module, and iLabs launched the Challenger+ RP2350 WiFi6/BLE5 board relying on ESP32-C6 wireless module. However, the Raspberry Pi Pico 2 W is the official board, is cheaper, and will certainly be the most popular/widely used. Raspberry Pi Pico 2 W specifications Raspberry Pi Pico 2 W specifications: SoC – Raspberry Pi RP2350 CPU Dual-core Arm Cortex-M33 @ [...]

The post $7 Raspberry Pi Pico 2 W board launched with 2.4 GHz WiFi 4 and Bluetooth 5.2 wireless module appeared first on CNX Software - Embedded Systems News.

Hello everyone. Another light week here. Let’s go over everything.

BeagleY-AI SD Card support

While hacking on my BeagleY-AI, I found that my HP SD card did not work with BeagleY-AI for some reason. On digging a bit further, some SD cards were not working on BeagleY-AI due to some issues with signal voltage switching on the am62x platform. This has now been fixed, as seen in the following patch series. By switching out the Linux kernel to mainline, I was able to get the HP SD card to work. So, the SD card compatibility of BeagleY-AI will improve soon.

BeagleBoard Rust Imager

BeagleBoard Rust imager got lots of love this week.

AppimageLauncher Problem

As pointed out by Jason here, the BeagleBoard Rust imager appimage is not usable with AppimageLauncher. The issue seems to be that appimagetool uses ZSTD compression now, while AppimageLauncher does not support it yet. Moreover, it seems like AppimageLauncher makes the appimage unusable. For now, the recommendation is to either remove AppimageLauncher or at least deactivate it for the BeagleBoard Rust imager.

More information regarding the upstream issue can be found here.

SD Card Flashing Performance Improvements

While the SD card flashing worked, it was much slower than the original bb-imager. After some tinkering with the buffer size while flashing and using parallel decompression of xz images, SD card flashing should be much faster (flashing time decreases by 57%).

It is still a bit slower than the original bb-imager (about 1 min), but it seems related to the internals of QFile, so that would be much more work than just a day.

Debian Packages

BeagleBoard Rust imager now builds Debian packages in CI using cargo-deb. While the goal is to eventually have an upstream package using debcargo, there is not much point until bb-imager-rs hits v1.0.0. Additionally, since debcargo only seems to support building stuff already present in cartes.io, it does not seem suitable for experimental builds (although I could be wrong about that).

Experimental Builds

Builds from the latest main branch are now pushed to Package Registry rather than just being stored as build artifacts. This makes grabbing the latest development version of bb-imager-rs much simpler.

Note: Only the most recent build is kept around.

Ending Thoughts

This was it for this week. Hopefully, this helps bring transparency regarding where the development efforts are concentrated, and how the community can help. Look forward to next update.

Helpful links

• BeagleBoard
• BeagleBoard Imager Rust Port
• My Rust std for UEFI open PRs

The post This Week in Beagle #6 appeared first on BeagleBoard.

While the end of year holidays are fast approaching, my commitment to Linux hardware and open-source software remains and there still is a lot of interesting content to come this year still -- each and every day, without change for roughly a decade. Unfortunately though due to the (sad) state of the ad industry, many major companies focusing on the likes of Facebook/Meta ads, and the frequent use of ad-blockers by Linux/FLOSS readers make ongoing operations increasingly difficult. But if you'd like to show some love this holiday season, the Phoronix Premium "Cyber Week" / "Black Friday" special is now taking place so you can enjoy the site ad-free, native dark mode support, multi-page articles on a single page, and other benefits while hopefully allowing the site to continue for years to come...

The nRF54L15 DK is a development kit designed to evaluate the wireless SoCs of the nRF54L15, nRF54L10, and nRF54L05 wireless SoCs. These SoCs support multiple wireless protocols, including Bluetooth Low Energy, Bluetooth Mesh, Matter, Thread, Zigbee, and 2.4GHz proprietary protocols, with data rates of up to 4Mbps. The kit integrates the nRF54L15 SoC and provides emulation capabilities for the nRF54L10 and nRF54L05, enabling flexible testing and development across the nRF54L Series. The nRF54L series SoCs differ in memory configurations to meet various application requirements. The nRF54L15 includes 1.5 MB of non-volatile memory (NVM) and 256 KB of RAM for high-performance applications. The nRF54L10 features 1.0 MB of NVM and 192 KB of RAM for mid-range use cases, while the nRF54L05 offers 0.5 MB of NVM and 96 KB of RAM for entry-level designs requiring fewer resources. The kit is supported by the nRF Connect SDK and tools, providing access to [...]

The post nRF54L15 DK: A Development Kit for nRF54L15, nRF54L10, and nRF54L05 SoCs with Bluetooth, Thread, and Zigbee appeared first on CNX Software - Embedded Systems News.

Don’t miss this opportunity to upgrade your CNC experience with the Genmitsu 4040-PRO MAX CNC Router and the Genmitsu APP with WiFi Module—a powerful duo designed for precision, performance, and convenience. 4040-PRO MAX: Revolutionizing Precision and Performance The Genmitsu 4040-PRO MAX is engineered to deliver top-tier CNC routing with exceptional accuracy and power. Its 400 x 400mm working area and 710W spindle make it perfect for both intricate woodworking and demanding metal engraving tasks. Enhanced Stability & Rigidity: This router’s upgraded Z-axis and linear guide rail system ensure unmatched precision and reduce vibrations for consistent results. Increased Z-axis Clearance: A 100mm pass height accommodates larger materials, making it versatile for diverse projects. Powerful Spindle: The 710W spindle cuts effortlessly through tough materials, earning rave reviews from users for its reliability and efficiency. Comprehensive Compatibility: This router offers endless customization and is compatible with most 4040 accessories, including routers, four-axis modules, [...]

The post Take Your CNC Projects to the Next Level with the Genmitsu 4040-PRO MAX and Genmitsu APP (Sponsored) appeared first on CNX Software - Embedded Systems News.

The T5 E-Paper S3 Pro is a compact development board featuring the ESP32-S3-WROOM-1 microcontroller alongside advanced capabilities. Designed for low-power applications, it integrates wireless connectivity, e-paper technology, and peripheral support This specific board is powered by the ESP32-S3-WROOM-1 module, which includes 16MB of flash memory and 8MB of PSRAM, supporting 2.4 GHz Wi-Fi and BLE […]

Waveshare has introduced a series of microcontroller development boards based on the RP2350 chipset designed by Raspberry Pi. These boards cater to diverse development needs, offering features such as GPIO expandability, 100 Mbps Ethernet, and compact LCD displays. The Waveshare RP2350-Plus Development Board is a versatile platform tailored for embedded development. Designed with compatibility in […]

ICP Deutschland recently introduced the TANGO-7010 series, a compact mini PC powered by Intel 12th-generation Core processors. Designed for demanding applications, the series features efficient thermal management with a system fan and supports various storage interfaces. The TANGO-7010 features the Intel H610 chipset and supports up to 64GB of DDR4 memory via two SODIMM slots, […]