postmarketOS is No More, At Least Under That Name

postmarketOS, the Linux-based operating system that many of you turn to for reviving your old smartphones, has undergone a name change, and it is now called "Nura."

This was announced during the project's conference recently, where the rebranding closed a long-running process that started last year in March, drawing more than 300 name submissions from the community.

It took a dedicated selection team and a trademark review aimed at accommodating languages from every continent to ensure that the new name didn't have any offensive meanings across different cultures.

postmarketOS had to go

The old name worked against the project in ways that compounded over time.

It was long, difficult to pronounce across many languages, and its mid-word capitalization had no obvious logic for anyone coming to it fresh. The project says that people were mischaracterizing it as "PostmarketOS," "Postmarketos," and "post-market OS."

Then there was the problem of scope; initially, when the project was focused on reviving old smartphones, it was an appropriate moniker to flaunt. But when PINE64 began shipping phones with postmarketOS pre-installed, it became a liability as they couldn't trademark a descriptive name.

That left the project with no legal standing to protect its identity against misrepresentation.

With Nura, a trademark application has already been filed, though it has not yet appeared in public trademark databases so far (I searched USPTO and EUIPO).

What's Nura?

Nura is short for Nuraghe, which are granite constructions scattered across Sardinia, Italy, with some of these being traced as far back as 3000 BC. Many of those structures are still standing, giving us a glimpse of what the Nuragic civilization built back in the day.

The project draws inspiration from that, seeing longevity as a direct match for its own goal of keeping smartphones useful for a decade or more.

The name itself came from Davide Depau, who submitted it during the project's open call for community contributions.

The selection team, consisting of Pablo C. Gómez, Pan Ortiz, Ranny Bergamotte, and Sriram Ramkrishna, worked through more than 300 submissions and narrowed the field to four finalists.

The team voted, and Nura won.

They also went for the .eco domain knowingly, as it is reserved for organizations committed to positive environmental change and comes with enforceable policies against greenwashing.

The project's current status

The new website presents a very straight-forward look at Nura's status, mentioning that it works best for people willing to learn how it works, contribute to testing, or help with development.

Its current release is v26.06, and for anyone getting started with Linux on mobile, the project points to second-hand Snapdragon 845 or Snapdragon 410/412-powered devices as the most sensible entry points.

Currently supported devices include the Fairphone 4, OnePlus 6 and 6T, PINE64 PinePhone and PinePhone Pro, Purism Librem 5, and several older Samsung and Xiaomi devices.

---

Suggested Read 📖: Your search for a Linux phone ends here.

from It's FOSS https://ift.tt/tnJzsxf
via IFTTT

GhostBSD is Replacing MATE With a New Desktop Named After a Typo

The man leading GhostBSD, Eric Turgeon, has come up with Mocka, a new desktop for this BSD distribution that would eventually replace MATE. So far, he has unveiled the dock that will go into it, as well as some preliminary concepts and specifications that show us where Mocka will head next.

Existing users of GhostBSD don't need to do anything now since nothing has changed on their machines. All of this is still under heavy development after all. 🤷

Grammar nazis won't like this

Eric has shown off a demo for the Mocka Dock.

In his search for projects named "Mocha," the caffeinated drink, Eric made a typo and ended up naming his new creation "Mocka," where every component has been built from scratch, taking in nothing from the MATE project.

He plans to replace one component at a time, reverse-engineering what MATE already provides until full feature parity has been achieved. Once this is complete, I assume that GhostBSD will default to using Mocka as its default desktop environment.

And this is not his first time carrying out such a major change. In February, he came to the conclusion that MATE was not ready for Wayland and GhostBSD would switch to XLibre to keep its X11 session intact.

That line of thinking also checks out with what Eric's doing now.

The desktop's first component, a taskbar-style dock applet for the MATE panel called Mocka Dock, is already out now as an alpha for early testers. It lets you open apps, view their thumbnails, bring them forward into focus, and manage multiple windows of an app—basically doing what a dock worth its salt should do.

People who have the skills can build it from source right now to see what it offers, while the rest of us will have to wait for it to show up as an GhostBSD package update. Though it is not becoming the default experience yet, you will have to manually set it using the "Add to Panel" button on the taskbar.

Mocka Dock

What's planned?

If you take a look at Mocka's GitHub page, you will get a better understanding of what's being worked on apart from the dock. There's Mocka Menu, which has a proper PLAN.md file that lays out what work has already been completed and what's to be done.

The document shows us how a meson build and schema work has been done, with a long list of work yet to be carried out. This would give Mocka the ability to show a menu with listed items, the ability to handle search and keyboard inputs, integrate with the dock, and much more.

Eric has plans for a settings app too. Once complete, it would give users a single-access point for managing their GhostBSD machine's desktop appearance, network config, power management, keyboard layouts, and other UI-focused options.

There's also a separate repo that hosts the code for Mocka's official website. It is considerably behind in terms of development than the menu component we saw earlier and only contained placeholder content at the time of writing.

The project is hoping to ensure that these new Mocka components remain compatible with MATE so that users can mix-match during this transitional phase to a full Mocka desktop on GhostBSD.

from It's FOSS https://ift.tt/Bl3u2Ms
via IFTTT

AlmaLinux Puts Software Certification in the Hands of Users

For the first time, there's a way to carry out software certification on AlmaLinux, and the hardware suite has been rewritten alongside it, with test results from either certification path landing in the same public catalog.

Don't worry about the cost to validate or the uptime of the machine itself. Certifications are free, and the hardware checks no longer require you to install the distro on your setup.

Validating, how?

In this particular situation, software certification is basically a listing plus the confirmations that follow it. A publisher adds the product and picks which major versions of AlmaLinux it runs on.

The confirmations come from the people running software on their own hardware across various AlmaLinux releases, though they will need to sign up for an account if they want to post their findings.

Hardware certification is the other half that got some attention.

The alma-certify tool has been rewritten, with the developers claiming it can now achieve sub-10 minute certification runs on most hardware.

Another improvement is that alma-certify doesn't require an AlmaLinux installation anymore because it can work off live media or from an installation already on the machine. There's also a new machine registration flow that makes use of QR codes.

If you didn't know, this tool records what's in the machine, all the way down to drivers and firmware, then starts up a bunch of short checks that decide whether it passes.

Those checks cover a lot of ground, starting from computation and memory errors, storage health, networking drivers, to kernel state, virtualization, GPU, and peripherals.

Tracking results

The catalog landing page (left) and the software certification page (right).

Everything ends up in the catalog, and each entry is a result anyone can analyze. It holds the systems, components, and software that have been validated, alongside the benchmark figures from the published test runs.

Every major AlmaLinux release is tracked on its own, so provenance can be proved, and everything in the catalog is easily searchable. You can even make use of the free, read-only API to collect data in bulk.

Jonathan Wright, the Infrastructure Lead for AlmaLinux, directed his attention toward potential testers, saying that:

Two things would make all of this worth it. A lot of people and organizations want proof that AlmaLinux runs on the hardware they already own before they’ll give it a try, and now they can get that proof themselves.

Every result that gets submitted makes the case to hardware and software vendors that supporting AlmaLinux officially is a low-effort thing to do.

So if you have hardware sitting in front of you, or software you rely on every day, go tell us that it works. Validations stack, so adding yours to something already listed helps just as much as being the first.

In the end, this will only work if vendors and individual users take the effort to run tests and manually post them on the portal.

---

Suggested Read 📖: Ubuntu is tightening its kernel SRU cycle to two weeks.

from It's FOSS https://ift.tt/tbD2PBe
via IFTTT

The Netherlands Built a Nix-Basd Linux Desktop Because Microsoft Cut Off the ICC

When the U.S. government imposed sanctions on the International Criminal Court (ICC) in early 2025, the consequences were far-reaching yet quickly enforced.

The restrictions cut off the ICC chief prosecutor's access to Microsoft services, including email, followed by a freezing of his personal and institutional bank accounts in affected jurisdictions.

While this was happening, the Dutch government was watching, coming to the bitter realization that access to essential services depended on decisions made in the U.S.

Hence, their response to this is DAWO, short for Digitaal Autonome Werkomgeving Overheid, or Digital Autonomous Work Environment for Government in English.

It is a framework that looks to tackle the government's digital stack, covering the OS, an office suite, collaboration apps, cloud services, IT management tools, and AI, with all of it being built around a NixOS foundation.

How it came to be

The DAWO initiative became an official government mandate in July, when the Interdepartmental Commission for Government Business Operations (ICBR) issued a directive for a standardized, sovereign digital work environment.

The three major IT service providers of the Dutch central government, SSC-ICT, DICTU, and DUO-ICT, are tasked with executing this major undertaking.

Development is handed by a team that is associated with the Ministry of the Interior and Kingdom Relations (BZK), with some notable people like Victor Gevers, Rutger Putter, and Bram Buijs being named.

Why go with NixOS?

Nix, the package manager NixOS is built around, handles configuration through its own functional programming language. Each package installs into an isolated directory with immutable, signed contents.

That makes a working setup reproducible across machines. For a rollout spanning dozens of agencies, that reproducibility adds up, resulting in substantially less repeated configuration work that would cost time and money.

Rutger estimates around 80 to 90 percent of a configuration carries over between deployments. NixOS also runs on hardware Windows 11 cannot, which is why the current pilots (more details below) are being run on decommissioned laptops that would otherwise be out of service.

For handling the code, this initiative is following a similar approach to the country's earlier Forgejo migration, where they moved their code hosting away from GitHub and GitLab.

All of DAWO's code is hosted on a Forgejo instance, with a separate Codeberg instance acting as the entry point for contributors. And, to answer the question asked earlier, NixOS was chosen because it is a Dutch project, with no company owning or controlling its development.

Before settling on it, the DAWO folks were considering openSUSE and Fedora. Both were disqualified due to their commercial ties, openSUSE to SUSE and Fedora to Red Hat, which in turn is owned by the US-based IBM.

Suggested Read 📖: Garuda Linux has begun pushing towards NixOS.

Things are looking up

Eight municipalities are running trial programs via the Association of Dutch Municipalities (VNG).

The ICC incident is what makes this different from other government-level open source pushes, as Dutch officials were given a first-hand reminder of what vendor dependency could cost them.

Of course they are not alone in doing so. Germany's Schleswig-Holstein went through something similar after leaving Microsoft. Part of what it used to spend on licenses now goes towards supporting open source projects.

Denmark and France have made similar moves of their own, where one is ditching MS services for their road traffic authority and the other is pushing a Linux switch across ministries, with 80,000 health insurance employees already moving to domestic tools.

As for where DAWO goes from here, they intend to release the first stable version sometime next year, taking in feedback from all the concerned parties (e.g., the municipalities).

Via: Tweakers

from It's FOSS https://ift.tt/6UgApXx
via IFTTT

This Tiny SBC Lets You Swap Interface Modules for Voice, Vision or Sensing

You get an SBC and start building projects on that. You start with a vision project. Then the next project idea needs audio. Perhaps the next one requires a bunch of sensors. Usually that means a stack of HATs on the GPIO header or getting a new SBC.

Vicharak is trying a different route with the Axon-Lite. It's a tiny ARM SBC whose interface modules are swappable, so you change the module to match the job instead of changing the board.

This "reconfigurable computing" pitch is what makes this ARM board slightly different from the rest.

Vicharak already offers a FPGA-based Vaaman and an RAM-based Axion line. The Axon-Lite is the smallest member of its Axon line. So they may be relatively new in this field, but they are not total novices.

Axion Lite Specifications

Let's see what you get on this SBC:

• SoC: Rockchip RK3576 (4× Cortex-A72 + 4× Cortex-A53)
• AI/graphics: 6 TOPS NPU, Mali-G52 MC3 GPU, 16MP ISP
• Memory & storage: LPDDR5 (2GB-8GB), eMMC 5.1 (32GB-128GB), UFS 3.1, SD card
• Modularity: swappable interface modules + board-to-board expansion
• Connectivity: Wi-Fi 6, Bluetooth 5.2, Gigabit Ethernet
• GPIO: Raspberry Pi-compatible 40-pin header

As you can already see, the highlight here is the modularity. The board uses what Vicharak calls its modular connector interface, and the idea is that you snap on a different interface module as needed.

The company shows four so far: Voice Processing, Smart Sensing, AI Data Hub and AI Vision. On top of that, there's board-to-board expansion, so you can stack a daughter board rather than swap.

board to board expansion

There's a but worth keeping in mind. A modular connector is only as useful as the module lineup that actually ships for it. And if this is a proprietary interface, not a standard one, so you will be dependent on whatever expansion board Vicharak is offering.

Under the modules sits a Rockchip RK3576. It's an octa-core chip that slots in above the entry-level RK3566 and below the flagship RK3588, which makes it a sensible middle ground for edge work.

Vicharak lists a 6 TOPS NPU alongside it, the same NPU figure you get on much pricier RK3588 boards, which is plenty for running vision and other on-device AI models locally. The company also claims the SoC is built on a TSMC 5nm process.

Memory is LPDDR5, and storage is flexible with eMMC 5.1, UFS 3.1 and a microSD slot all supported. The inclusion of faster UFS on a board this size is a nice touch.

Swappable Interface

For vision builds, the I/O is generous. You get a 4-lane CSI plus additional 2-lane CSI paths for cameras, a 4-lane DSI for displays, a 16MP ISP, micro HDMI 2.1 and USB-C with display output. Networking covers Wi-Fi 6, Bluetooth 5.2 and Gigabit Ethernet, and there's a Raspberry Pi-compatible 40-pin GPIO header so existing add-ons and pinouts carry over.

Vicharak also mentions on-board battery charging circuitry, which hints at portable, untethered builds.

Software and userbase

Vicharak is pitching the Axon-Lite as a Linux-first board, with a familiar Debian-style environment and the usual apt-driven workflow. Nothing exotic to learn here, in other words.

On the tooling side, the company lists the tools you'd expect for this kind of board: VS Code, Git, Python, Docker and Node.js for general development, and ROS 2, OpenCV, GStreamer, FFmpeg, Jupyter, TensorFlow Lite and ONNX Runtime for the AI, robotics and vision crowd.

Between that and the swappable modules, the target audience is quite spread as it is useful students, hobbyists and product teams prototyping edge AI and vision projects.

Pricing and Availability

Vicharak is pitching the Axon-Lite as a Linux-first board, with a familiar Debian-style environment and the usual apt-driven workflow. Nothing exotic to learn here, in other words.

From students tinkering with AI and embedded systems to hobbyists to product teams prototyping edge AI and vision projects, the target userbase for the board is quite spread.

Axon Lite is available for pre-order for the 4 GB and 8 GB RAM variants with a price tag of Indian rupees 15,930 (around US $165) and 18,299 (around US $200). The board should ship in January 2027. Please check for shipping and custom duty charges.

Pre-order Axion Lite

It is always interesting to see alternative single board computers, specially if they have something different to offer.

from It's FOSS https://ift.tt/B5YLzRI
via IFTTT

How openEuler Is Reinventing the OS Foundation for the AI Era with SuperPoD and UnifiedBus

The AI doesn't necessarily run on supercomputers (yet), it runs on clusters of hardware pieced together. This is where SuperPoD comes into picture. A SuperPoD is a tightly coupled scale-up system that connects many compute nodes so software can use resources across them more like one system.

So far, the operating system that ties them in a single machine has largely been proprietary. openEuler wants this to be open source, and its latest release shows the push for that.

Need for cluster OS

Linux provides the base for an excellent operating system. But mostly, the OS is confined to one machine. It schedules the memory, the CPU, and the devices inside a single box, and if you want more, you add another box and wire them together over the network.

This has worked so far, but the AI ecosystem demands more than that. Models now run across racks of machines that have to behave like one giant computer (SuperPOD, again), and the network in between becomes the bottleneck for performance.

openEuler is an open-source Linux distribution ecosystem, and its newest release ships focuses on running the whole cluster of AI machines as a single, unified system. The code is open and the community is showing interest in adopting it.

📋

A SuperPoD (also called supernode) is a large cluster of machines wired together closely in such a manner that software can treat the whole thing as one giant computer, rather than as dozens of separate servers.

A Linux distro built for SuperPOD

openEuler 24.03 LTS SP3, released in December 2025, was the first openEuler version built for SuperPoD. openEuler calls it the world's first OS to support this architecture.

openEuler supports SuperPoD through UnifiedBus and its OS software stack. UnifiedBus provides the high-speed interconnect, while the UB OS Component and UB Service Core provide OS and cluster-level services on top of it.

A normal Linux system schedules memory and devices inside one node. UB lets applications reach memory and accelerators sitting in other nodes almost as if they were local. So this openEuler release breaks the single-machine boundary and schedules these distributed resources as one single set.

And as you can see, it matters most for the AI hardware. openEuler also did some of its own tests and claims that the peer-to-peer UB design boosts application performance in large-scale AI compute up to 30 to 50 percent.

Where SuperPoD OS comes from

Let me give you some context to why it's called "world's first SuperPoD OS".

openEuler grew out of Huawei's in-house EulerOS and is now an open-source distribution stewarded by the OpenAtom Foundation. It runs across Arm (including Huawei's Kunpeng), x86, and RISC-V, and the project has passed 16 million installations by the end of 2025.

SuperPoD and UnifiedBus are Huawei technologies used across multiple computing systems, including Atlas AI systems and the TaiShan 950 SuperPoD for general-purpose computing.

The UB OS Component is open sourced in the openEuler community and forms part of openEuler's software support for UnifiedBus.

Intelligence BooM, the full-stack AI layer

Another interesting thing that openEuler is pushing for is Intelligence BooM, its open-source, full-stack AI solution. Full-stack here means that instead of running as a tool, it covers the whole software layer an AI workload needs from the OS up.

Basically, it gives you an out-of-the-box setup for training and running large models, so users don't need to do all the "AI plumbing" from scratch.

Underneath, openEuler keeps working on the low-level plumbing that makes clusters efficient: combining different chip types into one usable pool (heterogeneous compute fusion), letting CPUs and NPUs work on the same job together (co-computing), and sharing memory across chips and machines (memory pooling).

It also splits a single accelerator so several jobs can share it and packs more than one workload onto the same hardware, both aimed at keeping expensive NPUs and XPUs busy.

For regular Joes like you and me, the most interesting part is the DevStation, openEuler's desktop build, which ships with an AI assistant that should handle things like installing software or setting up an environment from natural language commands.

We plan to test DevStation and its openEuler Intelligence assistant on an openEuler 24.03 test machine for day-to-day development and general-purpose use.

Moving towards a community ecosystem

It is interesting to see that most of the open source and open-weight AI models are coming from China.

From the enterprise focused UB Service core to user-focused Intelligence Boom, openEuler is keeping things open and that's a step in the right direction. It is certainly a project to keep an eye on.

If you want to get involved, check out the community page or their GitHub repo for more details.

openEuler Community

from It's FOSS https://ift.tt/CLvjc4G
via IFTTT

Ubuntu is Tightening its Kernel SRU Cycle to Two Weeks, and Clankers Are to Blame

So far, Canonical has followed a split kernel SRU cycle for Ubuntu, where regular fixes and security patches lived on separate tracks, with a full update every four weeks and a security-focused release at the two-week midpoint for urgent CVE fixes.

If that concept is new to you, a Stable Release Update, or SRU, is how Canonical ships bug fixes and security patches to Ubuntu after a release is out. The kernel gets its own dedicated track for this.

Canonical is replacing both tracks with a single 2-week cycle, and since each new cycle kicks off a week into the current one, this results in a kernel release landing every week.

The new 2-week cycle

Source: Canonical

Each cycle starts with a week of patch integration and prep work. The kernel team selects which fixes land on each kernel, builds the packages, and runs basic smoke tests to catch anything obviously wrong before the build moves on.

Those builds get pushed into Ubuntu's -proposed pocket once the first week wraps up. That is where kernel release candidates live before they have been certified, accessible to those who know where to look but not yet out to general users.

Week two is where Canonical runs the builds through its Ubuntu Certified hardware testing program, putting them through different machine types to make sure nothing breaks in the real world before the kernel ships.

A fresh cycle starts every week regardless of where the current one stands, so there is always a kernel finishing its test run and rolling out. That is how a 2-week cycle ends up delivering a release every week.

And, when something is not safe to ship, Canonical says that they will be clear about that and direct users toward general system hardening advice.

For teams that cannot wait the full two weeks, Canonical is explicitly pointing to -proposed as a fast path. The idea is that you run your own acceptance tests on the build sitting there rather than waiting for certification to wrap up.

Clankers made this inevitable

This change did not come from nowhere; they had to take such a sweeping decision due to clankers. Only last month, we saw how they were bleeding compute resources from git.kernel.org just by scraping it for training data.

For Canonical, their decision was driven by LLMs and AI agents turning vulnerability hunting into something automated and relentless, finding kernel bugs at a scale and speed no individual human researcher could replicate.

The goal is to have a workaround published within 24 to 48 hours of a CVE going public. Not the patch, but something that gets affected systems into a safer state while one is being built.

What the Ubuntu maker is doing here is responding to a rapidly-evolving situation by shortening the window between a CVE going public and a patch landing.

from It's FOSS https://ift.tt/dD2fbhw
via IFTTT