 DistroWatch Weekly |
| DistroWatch Weekly, Issue 1147, 10 November 2025 |
|
Welcome to this year's 45th issue of DistroWatch Weekly!
The Fedora project is a testing ground for new technologies. People running Fedora often get to experience the latest versions of software and see previews of what will be showing up in future versions of Red Hat Enterprise Linux. This week we take a look at the recently launched Fedora 43 and report on its new features, new installer, and updated package management. Which flavour or spin of Fedora is your favourite? Let us know in this week's Opinion Poll. In our News section we report on the developer of Debian's package manager planning a move to include code written in Rust. This will help secure some parts of the APT code while expanding the package manager's dependencies. We also talk about Redox OS gaining new process monitors and a ported web engine while Flatpak development resumes. Plus we report on another issue in the Ubuntu family of community editions and the Mint team working on a new troubleshooting tool for desktop users. The FreeBSD project is making progress in terms of building their operating system in a reproducible manner and we share details below. This week, in our Questions and Answers section, we talk about the size of the Linux kernel. The kernel gradually gains new drivers and features over time and we discuss if and how this growth affects performance and stability. Plus we are pleased to share the new distribution releases of the past week and list the torrents we are seeding. We wish you all a wonderful week and happy reading!
This week's DistroWatch Weekly is presented by TUXEDO Computers.
Content:
- Review: Fedora 43
- News: Debian introduces Rust dependency into APT, Redox ports process monitors and web engine, Kubuntu website goes off-line, Mint introduces new troubleshooting tools, FreeBSD improves reproducible builds, Flatpak resumes development
- Questions and answers: Size and stability of the Linux kernel
- Released last week: Devuan GNU+Linux 6.0.0, umbrelOS 1.5.0, iodeOS 6.9, Murena 3.2, PorteuX 2.4, MX Linux 25
- Torrent corner: Devuan, FreedomBox, KDE neon, TUXEDO OS
- Upcoming releases: FreeBSD 15.0-RC2
- Opinion poll: Favourite flavour of Fedora?
- Site news: Front page filtering options
- Reader comments
|
| Feature Story (By Jesse Smith) |
Fedora 43
Every six months the Fedora project publishes a new release with the latest versions of open source software the community has to offer. This Red Hat-sponsored distribution recently published version 43 with a few notable changes from the previous release.
One of the key changes in Fedora 43 is the new system installer, which debuted in Fedora 42's Workstation edition and is now available across all editions. In addition, the main Fedora editions, Workstation and KDE, have moved to Wayland-only sessions with the X11 session options dropped. Behind the scenes, Fedora 43 introduces version 6.0 of the RPM package manager. The package manager change should go unnoticed by users, but sets up improved package signing for the developers.
I decided to try the KDE flavour of Fedora as it was elevated to be on par with the Workstation edition earlier this year. The download for Fedora 43's KDE edition is 3.0GB in size. Booting from this media brings up a menu offering to boot into the live desktop or perform a self-check on the live media.
Fedora 43 -- The Plasma desktop and application menu
(full image size: 1.3MB, resolution: 1920x1080 pixels)
Launching the live environment brings up the KDE Plasma desktop with a panel placed horizontally across the bottom of the screen. On the desktop we find a single icon for launching the project's new system installer. The panel and application menu are dark while applications use a light theme. Plasma's default wallpaper features a space theme with an image of the space shuttle launching into orbit. Once the desktop loads a welcome window appears. The welcome window offers to launch the system installer. If we ignore this offer the welcome window next provides a quick overview of KDE's desktop features and offers to enable third-party software repositories.
Once I had explored the desktop and confirmed the key elements of my system were functioning, I launched the system installer.
Installing
Once I had clicked the installer's icon nothing happened for about a minute. Then the installer's window opened and it spent another minute just sitting while text in the window told me it was "initializing".
The new installer has a blocky, flat look to it (much like openSUSE's new installer). Each screen of the process is painfully slow. Button clicks take several seconds to register and menus are slow to respond. The installer begins by asking us to select our language and keyboard layout from lists. Then we are asked to pick our timezone.
The next stage of the installer covers disk partitioning. While the installer will allow the user to select on which disk to install the distribution I could not find any way to select which partition(s) the installer should use or a way to create new partitions. The only option appears to take over the entire disk. This may be an effort to streamline the installer or a sign the new installer does not detect existing disk layouts properly. In either case it feels like a huge step backwards in terms of what the installer is capable of doing with a disk.
The next screens offer to encrypt the hard drive and ask us to make up a username and password for our user. There is a checkbox to enable a root account and set a password on it too. The installer then goes to work, very slowly copying files to the hard drive.
I was curious about this lack of performance form the new installer and did some looking into it. The new system installer uses 100% of all available CPUs the whole time it is running, even when it is sitting idly in background waiting for input. This causes my laptop fan spin up and run hard the whole time the installer is on the screen. I think the installer must have a bug in it which causes it to refresh its window constantly in an unchecked loop because the installer causes the kwin_wayland process (the window manager) to always consume all available CPU resources across all cores. Other applications, such as Dolphin, Firefox, and LibreOffice, do not have the same effect. The window manager sits near idle when those applications are open and interacting with the user. The system installer was the only application I could find which had this effect.
It seems nearly impossible that the Fedora team have made the old Anaconda installer (with its awkward disk management and its clunky hub screens) seem like a good alternative, but this new installer offers a terrible experience. Its steps are at least sequential, but the new disk partitioning options are almost non-existent and the performance is embarrassing.
Early impressions
My new copy of Fedora 43 booted to a graphical login screen where I could sign into my account to launch the Plasma desktop. This version of Fedora offers a Wayland session only, there is no longer a fallback option to run Plasma in an X11 session.
Upon signing in the welcome window appears once more and offers to show us an overview of the Plasma desktop and its elements. We are also told about key features the KDE project offers. The next screens of the welcome window offer to launch the Discover software centre and ask if we'd like to send telemetry to the developers. With these steps completed the welcome window leaves us to explore the Plasma environment.
Fedora 43 -- The KDE welcome window
(full image size: 801kB, resolution: 1920x1080 pixels)
The desktop's main elements (the panel and application menu) have a dark theme while application windows themselves (the file manager, text editor, and settings panel) use a light theme by default. The appearance of all elements can be adjusted in the System Settings panel.
The application menu makes use of transparency by default. The text has a high contrast to its background and this actually works fairly well, better than transparency usually does for desktop menus.
I found Plasma was fairly responsive in my test environments. Performance was about average - good, but slightly hampered by animations when using the default settings. These effects and other performance adjustments can be managed in the settings panel.
Hardware
I tested Fedora 43 in VirtualBox and on a laptop. The distribution worked well in VirtualBox, offering a stable experience and decent performance. The same could be said of the distribution running on the laptop. I found most of my hardware worked well. Networking, audio, and my touchpad all worked as expected. My touchpad was set up to handle taps and clicks which was convenient.
Fedora 43 -- The System Settings panel
(full image size: 1.1MB, resolution: 1920x1080 pixels)
There were a few quirks in the distribution's handling of my hardware. For example, my laptop's screen was set to a dim brightness level (17%), making it difficult to read. Usually I would use the laptop's shortcut keys (for adjusting brightness, volume, and media playing) to fix this, but they did not work. With some experimenting I found these shortcut keys would work if I held down the function (Fn) key at the same time. This behaviour is reversed in Fedora compared to every other distribution I have used.
The distribution is unusually heavy on resources. Fedora 43 used an unprecedented 2.2GB of RAM during my trial, just for logging into the Plasma desktop. This is about 30% larger than the next heaviest distribution I have ever run and about double the size of Linux Mint (running the Cinnamon desktop) and Kubuntu running the same version of Plasma. Since Fedora does not appear to offer any features above what those two distributions offer, its massive memory footprint seems like either a configuration issue or a case of the developers accidentally leaving their build system in "debug" mode". Fedora does not use a great deal of disk space though, with a fresh install using 5.4GB of space.
By default Fedora does not use any disk space for swap (either in a file or a partition), instead the distribution sets up a zRAM virtual device and compresses unused program memory inside RAM.
Software
The distribution ships with a few popular applications (such as Firefox and LibreOffice), but mostly sticks to software in the KDE family. The Dolphin file manager, KMail e-mail client, remote desktop viewer, Okular document viewer, and Gwenview image viewer all hail from the KDE community. We also find a system monitor, some games, and the KolourPaint drawing program. The Kamoso webcam manager is installed for us. I found the Dragon Player video player and the Elisa music player were installed. These players shipped with codecs for playing (most) media formats and I was able to use them to listen to music and watch videos. The video player did warn some video files might not be supported, but the videos I played worked properly.
Fedora 43 -- Using the Dolphin file manager and KWrite text editor
(full image size: 850kB, resolution: 1920x1080 pixels)
In the background we find Java is installed for us. The systemd software manages services, and the distribution ships with version 6.17 of the Linux kernel.
When working from the command line, if we try to run a program which has not been installed the shell will pause. It checks to see if it can find a matching program in the repositories and then, when a match it found, it will display a prompt asking if we want to install the missing package. This process is somewhat similar to what openSUSE and Ubuntu do when a program is missing. However, Ubuntu and openSUSE display results much faster, avoiding interrupting the user's flow on the command line. Also, Fedora stops us and displays a prompt rather than just showing the command which we could run to install the missing package. This is fine when it happens once or twice, but it quickly becomes annoying as each prompt needs to be dismissed before we return to working in the shell.
Fedora 43 -- Trying a dark theme
(full image size: 482kB, resolution: 1920x1080 pixels)
Package management
On the day Fedora 43 was launched I installed the distribution and soon found an icon in the system tray which indicated package updates were available. Clicking the icon launched the Discover software centre. Discover indicated it had one system update available, made up of 310 packages, which would be 2.2GB in size. Since the whole install ISO was 3.0GB in size, this would indicate a large portion of the operating system was being replaced right away on release day.
Discover reported it had successfully fetched and installed the updates and let me know I should restart the computer for the updates to be applied. This feels clumsy and out of date compared to how other distributions simply apply updates on the fly. To make matters worse, once I had restarted the computer I was using the DNF command line package manager and it reported the same 310 packages were available to be downloaded. I ran "sudo dnf update" and it successfully fetched and installed the updates (without requiring a reboot) and I was not prompted about it again.
Fedora 43 -- Fetching software with Discover
(full image size: 1.1MB, resolution: 1920x1080 pixels)
I had this same process happen a few days later. I had fetched updates using Discover and then, following a system restart, DNF found the same updates again. I asked a peer about this experience to see if they witnessed the same behaviour. They said a special button should appear in the shutdown/restart menu to trigger the second part of the update process. Since this wasn't happening, either there is a bug or I'm "rebooting wrong". Both explanations sound like buggy behaviour to me since, again, almost every other Linux distribution handles updates without requiring a restart at all, let alone one triggered by a specific command. Another explanation I came up with was a verification key might have been missing or untrusted. At one point I had to respond to a prompt from the DNF package manager to accept a new verification key and that hadn't happened when I was using Discover, which makes me wonder if Discover could have fetched updates and then silently rejected them due to the untrusted key. I don't know for sure, but in either case fetching package updates on Fedora is not a smooth experience.
Also on the topic of software management, Fedora ships with Flatpak support enabled. We can manage Flatpak bundles from the command line or from inside the Discover software centre. By default Fedora pulls from a custom repository of Flatpak bundles which matches the distribution's licensing ideals. However, there is a button in Discover's Settings page which will grant us access to the larger and more popular Flathub repository. Discover also has options for connecting us with third-party RPM package repositories that provide Steam, NVIDIA drivers, and Google Chrome. These are not enabled by default.
Fedora 43 -- Enabling extra repositories
(full image size: 705kB, resolution: 1920x1080 pixels)
Conclusions
Fedora is a testbed for trying out new technologies and an upstream development environment for Red Hat Enterprise Linux. As a result the distribution is regularly using new versions of software. This can make running Fedora a bit unpredictable because, on one hand, we are getting the latest features from upstream projects, but we are also getting the latest versions that have not yet been widely tested. Running Fedora can have some fun high points and some uncomfortable low moments.
On the positive side of things, the Plasma desktop was faster and its Wayland session was more polished on Fedora than when running Kubuntu on the same hardware. I didn't run into the issue of duplicate mouse pointers, for example, with Fedora. I like the layout of the Discover software centre. It may have had problems with providing updates, but it was able to fetch and install new packages without any issues. I also like that Discover can enable extra repositories.
While several distributions I have used this year have provided media players that struggled to play videos in a Wayland session, Fedora does not have this problem and was able to play videos right away.
There are some issues though. The slow response on the command line when trying to run a program that isn't installed (or when making a typo) interrupts my workflow. I also found DNF was slower than most other command line package managers.
Asking users to restart the computer to apply non-kernel updates feels about 30 years out of date and a painful return to Windows-style software management. Most other distributions do not do this, unless they are immutable. Fedora 43 "KDE" is not immutable, but it insists on this awkward behaviour with no benefit to the user.
The biggest problem with this release though is definitely the slow, CPU-intensive system installer. It makes the CPU run hot, even when it's idle, it has almost no disk partitioning and swap options, and it is painfully slow. I didn't think it was possible for Fedora to introduce a system installer I would like less than its previous version of Anaconda with its inconsistent menus and strange hub screens, but at least that installer had options. This installer has fewer options, it is slower, and its flat design is less attractive. I think it's nice to see Fedora return to a sequential install experience, but this feels like one step forward and three backwards.
On the whole, Fedora 43 has some good points and some problems. As usual, Fedora feels like an operating system which was assembled by separate committees who were not allowed to talk with each other. It results in some good points and some problems (as one might expect from a cutting-edge project), but it does not seem to have a consistent approach or design. It feels like a collection of beta releases, not an operating system intended to target a specific audience or solve a specific problem.
* * * * *
Hardware used in this review
My physical test equipment for this review was an HP DY2048CA laptop with the following
specifications:
- Processor: 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz
- Display: Intel integrated video
- Storage: Western Digital 512GB solid state drive
- Memory: 8GB of RAM
- Wireless network device: Intel Wi-Fi 6 AX201 + BT Wireless network card
* * * * *
Visitor supplied rating
Fedora has a visitor supplied average rating of: 8.3/10 from 476 review(s).
Have you used Fedora? You can leave your own review of the project on our ratings page.
|
| Miscellaneous News (by Jesse Smith) |
Debian introduces Rust dependency into APT, Redox ports process monitors and web engine, Kubuntu website goes off-line, Mint introduces new troubleshooting tools, FreeBSD improves reproducible builds, Flatpak resumes development
Debian developer Julian Klode has announced intentions to introduce Rust language dependencies into the APT package manager. Since APT is a central tool of the Debian distribution this raises a challenge for ports of the distribution which run on less popular CPU architectures where Rust does not yet exist. "I plan to introduce hard Rust dependencies and Rust code into APT, no earlier than May 2026. This extends at first to the Rust compiler and standard library, and the Sequoia ecosystem. In particular, our code to parse .deb, .ar, .tar, and the HTTP signature verification code would strongly benefit from memory safe languages and a stronger approach to unit testing. If you maintain a port without a working Rust toolchain, please ensure it has one within the next 6 months, or sunset the port." In particular it has been pointed out Rust does not run on the alpha, hppa, m68k, and
sh4 ports of Debian.
* * * * *
The Redox team are making progress with their Unix-like, open source operating system. The project's October newsletter mentions multiple new programs which have been ported to Redox OS, including "htop", "bottom", and the Servo web rendering software. "Wildan Mubarok successfully launched Servo after some effort to fix bugs and add missing functionality. Thanks also to Jeremy Soller, Andrzej J. Skalski, and other contributors that helped move it forward. Unfortunately, it crashes if a second website is loaded and it doesn't respond to keyboard input yet. We hope to make more progress in the near future." Details on these ports and new features can be found in the project's newsletter.
* * * * *
The past month has been a difficult one for people in the Ubuntu community. When Ubuntu 25.10 was released Flatpak bundles failed to work, or even install, on the distribution. Then it was revealed the Xubuntu website had been hacked and download links replaced with links to malware. Then it was discovered Ubuntu's new, Rust-based coreutils were missing functionality and blocking automatic updates. The latest issue comes from Kubuntu where a problem with the website's security certificate knocked the project off-line temporarily. The issue appears to have come about because the expiry date for the certificate was the same as the date it was created. The website administrator has been contacted and the community is awaiting a replacement certificate at the time of writing. Update: The Kubuntu website is back on-line.
* * * * *
The Linux Mint team have published their monthly newsletter for October which reminds users that Linux Mint Debian Edition 6 will reach the end of its supported life on January 1st, 2026. The newsletter also mentions new troubleshooting tools are being created to help Mint users gather information and get help with problems. "The 'System Reports' tool was given a plethora of new features and it was rebranded as 'System Information'. In addition to its 'System Information', 'System Reports' and 'Crash Reports' pages, the tool received 4 new pages to show you more information and help you troubleshoot common issues." Details and screenshots are provided in the October newsletter.
* * * * *
The FreeBSD Foundation has announced improvements to the operating system's build infrastructure. The new improvements allow FreeBSD to be built without administrator access on the build system. The FreeBSD Foundation has also reported progress in making reproducible builds: "Removing the need for root privileges in the build pipeline has reduced the attack surface and potential for privilege escalation. It enables safer and more flexible build environments, both for official infrastructure and for community contributors. In parallel with the no-root work, FreeBSD has introduced several changes to improve build reproducibility - ensuring that identical source inputs always produce identical binary outputs, byte-for-byte. These changes span the operating system itself, the release tooling, and the build process."
* * * * *
Back in May 2025 the OSNews website ran a story in which it was pointed out Flatpak development had largely come to a halt. This left Flatpak developers with a lot of issues to address without many people working on the big ticket items: "Flatpak still uses PulseAudio instead of PipeWire, which means that if a Flatpak applications needs permission to play audio, it also automatically gets permission to use the microphone. NVIDIA drivers also pose a big problem, network namespacing in Flatpak is 'kind of ugly', you can't specify backwards-compatible permissions, and tons more problems. There's a lot of ideas and proposed solutions, but nobody to implement them, leaving Flatpak stagnated."
The good news, for Flatpak fans, is the project is now working on these problems. The Linuxiac website reports: "In his latest blog post titled Flatpak Happenings, Wick acknowledged that Flatpak had reached a stagnant phase earlier in 2025, with development slowing and open contributions piling up. Fortunately, development has now restarted thanks to renewed efforts from long-time contributors along with new maintainers stepping up to review and merge code more actively. Now, the project has been reorganized, streamlined its review process, and reestablished an active development rhythm." The report also mentions Flatpak's sparse documentation is being improved.
* * * * *
These and other news stories can be found on our Headlines page.
|
| Questions and Answers (by Jesse Smith) |
Size and stability of the Linux kernel
Size-goes-before-the-fall asks: So I've heard that there is a bug in something like every ten lines of code written. If that's true then won't Linux get less stable as it gets bigger? How big can the kernel get before it's got more holes than Swiss cheese?
DistroWatch answers: Humans are imperfect and developers write code which contains mistakes. Sometimes these mistakes are minor typos, other times they are faulty assumptions, and sometimes they are memory vulnerabilities which could cause instability in a program.
Depending on who you ask, the average number of bugs in a given number of lines of new code can vary quite a bit. Depending on the source of the statistics, I've encountered numbers ranging as high as one bug per ten lines of new code (1:10) to as low as one bug for every two thousand lines (1:2000). The number tends to vary depending on the organization, the coding language being used, and whether the code is in its development phase or in production. In other words, code being written the first time will have more bugs than code which has been peer reviewed and has some tests run on it to find common mistakes.
Regardless of the exact ratio, there is some truth to the idea that for every N number of new lines of code written, there will eventually be some bugs.
Next, let's look at the Linux kernel. The Linux kernel reached approximately 40 million lines of source code (40,000,000) earlier this year. This is double the size of Linux's code from ten years ago when it passed the 20 million lines of code milestone.
If we go back and look at our earlier statistics for bugs-to-lines ratio, that would mean the kernel contains anywhere from 20,000 to 4,000,000 errors, right? Well, fortunately, no, this is not the case. There are several reasons why the kernel doesn't leak errors like a rusty sieve. Code entering into the kernel goes through a review process. One person writes the new code, a tool or two check it for common problems, another person who is experienced in maintaining that part of the kernel reviews the code, and then it gets passed up the chain. By the time the new code lands in a kernel release that you or I are going to run on our computers at home or at work, it has passed through multiple reviews.
Another big factor to consider is that a large portion of the kernel's new code is in optional modules. A lot of the new development which ends up in the kernel's source code is for hardware drivers or other optional components which are only loaded into memory as needed. This means there may be thousands of drivers supported in the kernel's source code, but only the handful you need to run your own equipment are actually being run on your computer. It doesn't matter (from your point of view) how many bugs are in new drivers which don't run on your machine. Those modules aren't loaded into memory and so won't affect your machine's stability or security.
One more aspect of code development to consider is that there may be 1 bug in every N lines of code when writing new functionality, but those bugs can be found and fixed over time. Over the months and years a significant number of problems are found and fixed. Unless you are running a cutting-edge distribution, chances are new kernel code will be running in the real world, getting tested and fixed, for months before it lands on your computer. This means even when a bug makes it into a published kernel, it is often found and fixed before it reaches the desktops and servers of most people running Linux distributions.
Going back to the original question - yes there are often bugs in new code as it gets written. However, the reason every large software project isn't a terribly flawed mess is that code doesn't stay "new". It gets reviewed, it gets tested, it gets patched, it gets battle tested in the world, and it is refined over time.
* * * * *
Additional answers can be found in our Questions and Answers archive.
|
| Released Last Week |
Devuan GNU+Linux 6.0.0
Devuan GNU+Linux 6.0.0, code name "Excalibur", has been released. This latest version of the project's systemd-free Linux distribution forked from Debian in 2015 is based on Debian 13: "It is with great pleasure that the Devuan developers hereby announce the release of Devuan Excalibur 6.0 as the project's newest stable release. This is the result of lots of painstaking work by the team and extensive testing by the wider Devuan community. New in this release: a [merged-/usr]filesystem is obligatory, if you are upgrading from 'Daedalus' ensure you have complied with this requirement before upgrading; PipeWire audio - in general (with the notable exception of users requiring a screen reader for graphical login), the PipeWire media server is a superior solution to PulseAudio, in particular it has fewer latency issues; non-free firmware - all Devuan 6 installation media make non-free firmware packages available at install time, in the majority of the cases, these packages are needed (and will be installed) only if your hardware (usually WiFi adapter) requires them." See the brief release announcements and the detailed release notes for further information.
Devuan GNU+Linux 6.0.0 -- Running the Xfce desktop
(full image size: 142kB, resolution: 2560x1600 pixels)
umbrelOS 1.5.0
Umbrel, Inc. has announced the release of umbrelOS 1.5.0, the latest version of the company's Debian-based Linux distribution for home servers, available for standard 64-bit and Raspberry Pi computers. The distribution features a web-based user interface and an online app store with a large range of applications - anything from web hosting, productivity and finance to media streaming, networking, automation, artificial intelligence, development and Bitcoin mining. Version 1.5.0 delivers a number of improvements: "umbrelOS 1.5 brings automatic encrypted backups, Rewind in Files, network drive mounts, external USB storage and formatting support on amd64 devices, GPU acceleration for apps, and several performance improvements and bug fixes. New features: backups - umbrelOS can now automatically back up all of your files, apps and data to another Umbrel or a NAS on your network, or an external USB drive; Rewind in Files - time travel through your backups to restore specific files and folders from any point in the past; network mounts in Files - mount network drives and shares, like another Umbrel or a NAS, and browse them directly within Files...." Read the release notes on the project's GitHub pages for further details.
iodeOS 6.9
The iodeOS team have announced the availability of iodeOS 6.9. The new version focuses on security and user accounts, enabling auomatic reboot after a period of inactivity, full signing out of user accounts, and better protection of device settings. "Full Logout for Secondary Users: Secondary users can now be fully logged out of the device, rather than just switching accounts. This ensures a cleaner separation of user environments and better privacy for everyone sharing the device. Also included in iodéOS 4 and later versions. Private Space and Work Profiles for Secondary Users: Secondary users can now use Private Space and Work Profiles, allowing them to leverage apps like Shelter for better data isolation. This is ideal for families or teams who need to keep personal and work data separate, even on shared devices. Work Profiles also included in iodéOS 5.App links (deep links) let apps open specific URLs directly instead of defaulting to the browser. With iodéOS 6.9, apps can now automatically validate these links if configured, eliminating the need for manual approval and making the experience smoother and more efficient." The project's release announcement has further details.
Murena 3.2
The Murena team have announced a new version of their /e/OS operating system for mobile devices. The new 3.2 version features notifications when apps are leaking data and customization options for the side button on the Fairphone 6. There are also improvements to the project's software centre: "In Advanced Privacy, users are now informed in real time when apps attempt to leak data, with simple controls to manage notifications. The App Lounge has also been refined: app sizes from F-Droid are now displayed, and common apps are shown based on region for a better browsing experience. For Fairphone (Gen.6) users, /e/OS 3.2 introduces customization of the side button, allowing you to assign your preferred actions. While the dedicated Moments feature from Android is not yet available, this new customization gives you more flexibility in how you use the button. A major improvement has been implemented to the Fairphone (Gen.6). Fairphone Camera app is now available on /e/OS, enjoy an even better camera experience on your phone." Additional details are offered in the project's newsletter and in the release notes.
PorteuX 2.4
The PorteuX development team has release PorteuX 2.4, the latest version of the project's set of lightweight and stripped-down Linux distribution featuring a number of popular desktop environments. This release presents a new desktop option, the COSMIC desktop developed by System 76: "This release brings the COSMIC desktop environment for 'current'. Bear in mind it's still in beta, so expect many issues, including cosmic-osd running at full CPU load (already reported). This is the last PorteuX release that will include a version based on Slackware stable. After much consideration, we decided that this version is just too old and brings no advantage over the current version, which is extensively tested before each PorteuX release. Changes: fixed date/time during boot time; fixed cheatcode from using UUID not having a trailing slash; fixed Cinnamon rendering in Wayland; fixed cropped title bar in Xfce; fixed small title bar icons in Openbox...." See the changelog for a complete list of changes and bug fixes.
MX Linux 25
The MX Linux team have announced version 25 of their distribution is now available. MX Linux 25 is based on Debian 13 "Trixie". The release announcement shares key new features: "MX-25 is now available for use. MX-25 is built from Debian 13 Trixie and MX repositories. All releases come with systemd. The Xfce, Xfce-AHS, and Fluxbox releases are also available in sysVint variants. sysvVinit ISOs are clearly labeled such in the file name. Reasons for this change from past editions are in this blog post. Major Desktop versions: Xfce 4.20, Fluxbox 1.3.7, KDE/Plasma 6.3.6 Most ISOs come with the latest 6.12.48 kernel from the debian stable repositories. The Xfce AHS variants have 6.16 Liquorix kernels. The antiX live system has been modified to work better with systemd as the init system. To those that want to run live systems as a primary system, the sysVinit versions better support the antiX live system. The Qt based gui MX Tools have been migrated to Qt 6. Most apps have also received bug fixes and translation updates. Our long time updater tool, apt-notifier, has been replaced with a new tool, mx-updater. Functionally they are very similar, but under the hood there are some additional tricks and preference options, including the ability to use nala as the backend rather than APT."
MX Linux 25 -- Running the Xfce desktop
(full image size: 2.4MB, resolution: 2560x1600 pixels)
* * * * *
Development, unannounced and minor bug-fix releases
|
| Upcoming Releases and Announcements |
|
Summary of expected upcoming releases
|
| Opinion Poll (by Jesse Smith) |
Favourite flavour of Fedora?
This week's Feature Story talked about Fedora, a cutting-edge distribution which is sponsored by Red Hat. Fedora is available in many flavours, including two main desktop editions (Workstation and KDE), a Server edition, several atomic editions, and many community spins. Which one of these is your favourite?
You can see the results of our previous poll on preferred methods to manage a server in our previous edition. All previous poll results can be found in our poll archives.
|
Which flavour of Fedora is your favourite?
| Cloud: | 3 (0%) |
| CoreOS: | 11 (1%) |
| IoT: | 5 (0%) |
| KDE: | 391 (36%) |
| Server: | 12 (1%) |
| Silverblue/Kinoite/Sway Atomic: | 122 (11%) |
| Workstation: | 314 (29%) |
| One of the spins: | 215 (20%) |
| One of the labs: | 13 (1%) |
|
|
| Website News |
Front page filtering options
When DistroWatch got started, over 20 years ago, the website tracked just a handful of Linux distributions. These Linux distributions might run on desktops or on servers, but there was a small selection. As such, if you visited our front page some of the few search/filtering options were to display announcements for "Development" releases or "Stable" releases.
Over time, the site added new categories of open source software operating systems. Members of the BSD and OpenSolaris communities were added to our database, along with Haiku and MINIX. In the past decade we have also started posting announcement for some open source mobile operating systems. The announcement database has grown to over 12,000 announcements and filtering these are beyond the capability of a simple Stable/Development toggle.
With this in mind we have adjusted the filters at the top of the front page announcements. Now, under the Releases drop-down menu, our readers can select from a wider range of announcement categories. The new collection of categories are as follows:
- All - display all announcements and newsletters
- Stable Linux - all stable releases of standard desktop/server Linux distributions
- Weekly - see past issues of our newsletter
- Development - all development releases (alpha, beta, and release candidates)
- BSD - all stable releases from the BSD communities
- Mobile - all stable mobile releases
- Other OS - any open source operating system not covered by the above options
We hope these new filters will help our visitors more easily find the new items which interest them.
* * * * *
DistroWatch database summary
* * * * *
This concludes this week's issue of DistroWatch Weekly. The next instalment will be published on Monday, 17 November 2025. Past articles and reviews can be found through our Weekly Archive and Article Search pages. To contact the authors please send e-mail to:
- Jesse Smith (feedback, questions and suggestions: distribution reviews/submissions, questions and answers, tips and tricks)
- Ladislav Bodnar (feedback, questions, donations, comments)
|
|
| Tip Jar |
If you've enjoyed this week's issue of DistroWatch Weekly, please consider sending us a tip.
(Tips this week: 2, value: US$16) |
|
|
|
 bc1qxes3k2wq3uqzr074tkwwjmwfe63z70gwzfu4lx  lnurl1dp68gurn8ghj7ampd3kx2ar0veekzar0wd5xjtnrdakj7tnhv4kxctttdehhwm30d3h82unvwqhhxarpw3jkc7tzw4ex6cfexyfua2nr  86fA3qPTeQtNb2k1vLwEQaAp3XxkvvvXt69gSG5LGunXXikK9koPWZaRQgfFPBPWhMgXjPjccy9LA9xRFchPWQAnPvxh5Le paypal.me/distrowatchweekly • patreon.com/distrowatch |
|
| Extended Lifecycle Support by TuxCare |
|
|
| Reader Comments • Jump to last comment |
1 • Debian Rust implementation/ Filtering options (by Keith S on 2025-11-10 02:05:25 GMT from United States)
I'm concerned enough about Debian's rewrite of APT in Rust that I'm thinking of switching from MX Linux and antiX to EndeavourOS or some other Arch spin. The mantra is that "It's memory-safe!" but rewrites are just new, untested code that is more likely to have bugs. You don't have to look farther than Ubuntu's new rewritten coreutils for evidence.
I tried the new filters under Release for news articles and love it. This is what continuous improvement looks like.
2 • Fedora 43 Review (by Slappy McGee on 2025-11-10 02:13:38 GMT from United States)
This is one of those times (and I've seen a few over time) when my experiences with a reviewed distro are nothing at all as reported in the review.
Installing and running Fedora 43 has been nothing but (cool) joy, and it's going to remain on this machine for the foreseeable future (which often means the next 6 month update.. hopefully not this time)... hoping that 44 does not mess things up.
I feel they uncorked a great one with 43. Everything installed and works as expected. Given I do not use the command line much for installation of packages etc; perhaps that's an area that I would feel differently about if I ran into the reviewer's description of how that went for him.
I don't know what else to say. :o)
3 • Which flavour of Fedora is your favourite? (by jorge on 2025-11-10 03:34:46 GMT from Argentina)
Anyone
4 • re: Debian Rust implementation/ Filtering options (by InvisibleInk on 2025-11-10 03:40:32 GMT from United States)
@ #1
I'm not too concerned about this, or really anything else they are up to. I'm sticking to stable Trixie, and I won't be running testing or sid, so none of this is likely to affect me.
I feel like, if they are going to do this, the earlier the better, and that they are will test the hell out of this before Forky is released sometime in late '27.
5 • Fedora 43 (by Rich on 2025-11-10 04:04:53 GMT from The Netherlands)
I have seen the same review about Fedora a couple of years ago, thats odd is it not?
6 • Don't force rust in apt (yet) (by no rush for rust on 2025-11-10 04:36:19 GMT from United States)
@ # 1
Rust coreutils is a big deal but one can always revert to the GNU coreutils.
The bigger issue is enforcing rust in apt within 6 months. Too fast is not good for debian. Not sure how long it will take to port rust to these platforms but 6 months seems too soon seeing that debian 13 was just released. They should delay the rust migration by 1 year, so users can choose between c-apt and rust-apt for debian 14. Then the devs can require rust-apt in debian 15. Dont rush the rust!
7 • Fedora's flavour (by Jyrki on 2025-11-10 04:54:46 GMT from Czechia)
Despite fact I started with Red Hat Linux 4.2 Biltmore way back in 1996, nothing could be more distant to my current taste than Red Hat and Fedora.
In fact, in my eyes, Red Hat is Microsoft of Linux world as they violitating it, taylor making for their own purpuse and needs and stealing it off from Linux community.
8 • Fedora 43 (by BlueIV on 2025-11-10 04:55:36 GMT from United States)
I think a component of varying experiences with any particular distro release is the large amount of different hardware that is being used. I have had different results than others sometime report and even on my different machines. This seems to happen more often with smaller distros but can even happen in larger projects (and between releases as I'm sure everyone has experienced).
9 • Distro review (by makosol on 2025-11-10 05:56:24 GMT from France)
It would be vert useful to mention which hardware was used for distro testing, as experience may vary very much with it.
10 • Fedora (by Fleck on 2025-11-10 06:07:47 GMT from Australia)
Jesse, in your opinion poll you should include the option; don't use fedora or never plan on using fedora or something like that
Regarding the Linux kernal 40 million lines of code; how much of that are binary blobs for devices?
The development of the kernel does not appear to be sustainable in the long term. At what point will we all realize that monolithic designs like this can't continue to grow exponentially.
Redox OS has the right idea; microkernel design which focus on user-space, unlike Monolithic kernels which focus on kernel-space.
Just waiting on Redox to hit a stable release before jumping the linux ship. Alternatively, perhaps Gentooize my linux experience and recompile the kernerl removing all the unecessary crud post install
11 • @9 -- He always lists his testbed hardware (by eco2geek on 2025-11-10 06:36:11 GMT from United States)
It's at the end of the review, e.g.
---
"Hardware used in this review
My physical test equipment for this review was an HP DY2048CA laptop with the following specifications:
Processor: 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz
Display: Intel integrated video
Storage: Western Digital 512GB solid state drive
Memory: 8GB of RAM
Wireless network device: Intel Wi-Fi 6 AX201 + BT Wireless network card"
---
12 • Rust in APT (by Josh Smith on 2025-11-10 07:00:20 GMT from Australia)
@6 I agree wholeheartedly. One of the main pros of Debian is its portability and it seems like the team is shooting itself in a place I'd rather not mention by adding Rust to APT with only 6 months' notice.
13 • Reboot after updates (by Nullbuddy on 2025-11-10 08:23:59 GMT from Germany)
@Jesse: Rebooting after updates is technical the right thing to do (TM). To the best of my knowledge, there is no Linux system on the market which restarts the correct services/applications after an update.
Knowing above, it does not mean that I will reboot my system after non-kernel updates, or that I often run into trouble by not rebooting my system, but I am at least aware enough to restart my browsers or webservers/firewalls, if a component of them is updated.
OTOH I run Debian, so the deltas between an update should just be a security patch or a minor bugfix, where in Fedora one could jump a major version. Even in Fedora one can easily update the whole system via DNF from the CLI, w/o rebooting.
tl;dr: Asking for a reboot after a software update is IMHO the right thing to do and a good default for most users. Could we fix this in theory? We could, but I'd rather thave engineering energy invested in a lot of other areas first.
14 • Apt Rust (by Hank on 2025-11-10 08:24:03 GMT from Germany)
Mr julian klode is the Uuntu core developer / Debian dev who has announced he will
break apt for many devices by forcing a Rust Toolchain in to Debian.
Quote:
It's important for the project as whole to be able to
move forward and rely on modern tools and technologies
and not be held back by trying to shoehorn modern software
on retro computing devices.
Thank you for your understanding.
Problem is in its core a statement by present Debian Leader.
if you think its right do it
That is capitulation not leadership
It has already led to problems for other distros who use alternatives to system D, they are yet again being hit despite a General Resolution to not do so.
At the core Debian is being ever more removed from its original core mission, being the universal operating system.
Notably the persons involved are systemD evangelists, IBM Rhel and Ubuntu deeply involved.
15 • MX Linux 25 KDE (by Tony Smith (UK) on 2025-11-10 09:37:16 GMT from United Kingdom)
Years and years ago, my first adventure into Linux was Mepis, and I was excited that MX had been released. I installed this after Distro-hopping around the world, learning that my preference is a Debian based Distro with KDE. Not being an expert, simplicity is important to me, so I was delighted to find the whole process smooth, fast and simple and MX meets all of my requirements, Debian-based and KDE. The distribution is both smooth and quick, and it is obvious that the developers have used their vast experience to bring a superb product to us.
Thank you so much for your thought and expertise and MX Linux is the best I have used.
16 • Tony Smith (by linuxseekers on 2025-11-10 09:59:36 GMT from Malaysia)
Mine all-time were Mandrake,
Red Hat 9, and Suse 6.1
I reviewed Mepis 20 years
ago because i really like its
slimness.
17 • Selectable systemd/sysv unofficial respin for MX available (by Uncle Slacky on 2025-11-10 10:54:40 GMT from France)
Apparently someone has managed to incorporate both inits in a single ISO (as in previous versions of MX) - it's unofficial for the moment at least: https://forum.mxlinux.org/viewtopic.php?t=86241
18 • Restart (by Jesse on 2025-11-10 11:35:27 GMT from Canada)
@13: > "Rebooting after updates is technical the right thing to do (TM)."
Why do you think that? There is no technical reason an operating system needs to reboot after applying updates, especially these days in the era of live kernel patching. At most, we need to restart a few services to get all the benefits of all new patches.
> "To the best of my knowledge, there is no Linux system on the market which restarts the correct services/applications after an update."
openSUSE can do this. All the projects in the Debian family can do this. Fedora seems to be the only one pushing this idea a reboot is required. Which is especially strange since Red Hat (their downstream and sponsor) has been one of the biggest advocates of live patching to avoid system reboots.
19 • Hardware Fedora 43 Used On (by Slappy McGee on 2025-11-10 11:45:26 GMT from United States)
@9 inxi yields:
12Machine:
12Type Laptop 12System Acer 12product Aspire A517-52 12v V1.26 12serial
12Mobo TGL 12model Jasmine_TL 12v V1.26 12serial 12UEFI Insyde 12v 1.26
12date 03/14/2022
12Battery:
12ID-1 BAT1 12charge 33.5 Wh (95.4%) 12condition 35.1/48 Wh (73.1%)
12CPU:
12Info quad core 12model 11th Gen Intel Core i7-1165G7 12bits 64 12type MT MCP 12cache 12L2 5 MiB
12Speed (MHz) 12avg 4100 12min/max 400/4700 12cores 121 4100 122 4100 123 4100 124 4100 125 4100 126 4100 127 4100
128 4100
12Graphics:
12Device-1 Intel TigerLake-LP GT2 [Iris Xe Graphics] 12driver i915 12v kernel
12Device-2 Quanta HD User Facing 12driver uvcvideo 12type USB
12Display wayland 12server Xwayland 12v 24.1.9 12compositor kwin_wayland 12driver 12gpu i915
12resolution 1920x1080~60Hz
12API EGL 12v 1.5 12drivers iris,swrast 12platforms gbm,wayland,x11,surfaceless,device
12API OpenGL 12v 4.6 12compat-v 4.5 12vendor intel mesa 12v 25.2.6 12renderer Mesa Intel Iris Xe Graphics
(TGL GT2)
12API Vulkan 12v 1.4.321 12drivers intel,llvmpipe 12surfaces N/A
12Info 12Tools 12api clinfo, eglinfo, glxinfo, vulkaninfo 12de kscreen-console,kscreen-doctor
12wl wayland-info 12x11 xdriinfo, xdpyinfo, xprop, xrandr
12Audio:
12Device-1 Intel Tiger Lake-LP Smart Sound Audio 12driver sof-audio-pci-intel-tgl
12API ALSA 12v k6.17.7-300.fc43.x86_64 12status kernel-api
12Server-1 PipeWire 12v 1.4.9 12status active
12Network:
12Device-1 Intel Wi-Fi 6 AX201 12driver iwlwifi
12IF wlp0s20f3 12state up 12mac
12Device-2 Realtek RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet 12driver r8169
12IF enp1s0 12state down 12mac
20 • Fedora 43 KDE (by Aroldo on 2025-11-10 11:59:55 GMT from Italy)
Fortunately the "Everything ISO netinstaller" still has the old anaconda and it allows you to choose any of the available desktop environments.
21 • Reboot after updates (by Giacomo on 2025-11-10 12:04:31 GMT from Italy)
@13
"Asking for a reboot after a software update is IMHO the right thing to do and a good default for most users."
I also think so.
22 • Rust (by Keith S on 2025-11-10 13:57:40 GMT from United States)
It's interesting to me that The major distros are pushing Rust hard after it was shut out of the kernel. The reflexive conspiracy theorist in me wonders if it isn't another route to trying to force Rust into the colonel eventually. The supposed benefit of Rust is that it is memory safe, but well-written C is memory safe as well, and is easier to read. But if your goal is to eliminate human developers so that all your code can be written by AI, then Rust might be the better choice. Again, I admit that I am reflexively distrustful of projects that are controlled by billionaires, so this is just speculation.
23 • AI comments (by Keith S on 2025-11-10 14:00:10 GMT from United States)
Yes, my previous comment was written using AI voice recognition. But it is memory safe and I'm sure that humans can rewrite the errors in their minds to be able to understand it.
24 • Rust and apt (by DaveT on 2025-11-10 14:51:42 GMT from United Kingdom)
Does Julian Klode have the right to decide all by himself that he will introduce Rust dependencies into apt?
Surely that is a major decision that needs to be made by some committee or other.
I use Devuan - I hope they can manage to keep their own Rust free version of apt going...
25 • Rusty apt and debian derivatives (by A hobbit on 2025-11-10 16:10:55 GMT from Chile)
Im really interested in how are the many debian derivatives going to react to rust-apt. Devuan in particular, since I have a soft spot for the project and its origin.
26 • Reboot after updates (by Eric on 2025-11-10 16:53:25 GMT from Sweden)
@13
> To the best of my knowledge, there is no Linux system on the market which restarts the correct services/applications after an update.
There is a package for this purpose called "needrestart", it is used by default at least on Ubuntu Server AFAIK, it runs after update via a hook mechanism in dpkg or APT. There is also an older utility "checkrestart" in the "debian-goodies" package which can be run manually.
27 • @15 MX Linux 25 KDE (by Geo. on 2025-11-10 16:56:22 GMT from Canada)
Agreed Mepis was a wonderful breath of fresh air. I found the ease of installation, set-up, and everyday use to be top shelf. I'm so glad it came back as MX. Great team on that distro. Thank you, MX crew, for your dogged efforts.
28 • Fedora (by David on 2025-11-10 16:59:18 GMT from United Kingdom)
My favourite Fedora? Well, the first distro I installed for myself was Fedora 1, and that wasn't bad. The last one I used was Fedora 10, by which time I was tired of being used as a guinea pig.
29 • Memory safety (by Eric on 2025-11-10 17:35:15 GMT from Germany)
@22:
No, "well-written C" is not (usually) memory-safe. Memory safety is a property of language and its runtime environment, not of particular program or library. It must be impossible (by default, without using non-essential and optional "unsafe" constructs) for a memory-safe language to write a program which can (accidentally) corrupt an unrelated memory object when modifying a different one. It is possible to make C memory-safe by compiling with AddressSanitizer and UndefinedBehaviorSanitizer or similar runtime libraries, but this incurs a huge memory overhead, and execution speed also slows down roughly 2x or more.
The next C++ standard is going to include memory safety extensions, so it will be possible to rewrite APT in memory-safe C++ subset.
30 • Size and stability of the Linux kernel (by Eric on 2025-11-10 17:43:40 GMT from Germany)
Well, the Linux kernel IS actually incredibly buggy, just see a list of circa 100 vulnerabilities fixed in each Ubuntu kernel update every week. There are parts of code that nobody really understands. Remember why you cannot scroll back in virtual consoles anymore.
31 • Rust in Debian APT? (by JeffC on 2025-11-10 17:59:54 GMT from United States)
The biggest problem with Rust in Debian is that Rust is a fast moving target, the final specification for the Rust language has not yet been released.
Debian will end up supporting code long abandoned by upstream in their core package management system.
The response from the Rust devs will most likely be to tell them that they should update to a newer Rust, but Debian Stable cannot do this.
32 • APT (by Jesse on 2025-11-10 18:36:07 GMT from Canada)
@24: "Does Julian Klode have the right to decide all by himself that he will introduce Rust dependencies into apt?"
Yes, of course. The author of a project has the right to do whatever they want with it.
"Surely that is a major decision that needs to be made by some committee or other."
Debian has a committee which can decide whether to adopt the new version of APT. But they can't tell developers what to work on in their own time.
@25:
"Im really interested in how are the many debian derivatives going to react to rust-apt. "
That's easy: zero. Rust runs on almost all the architectures downstream distributions use.
33 • @13 Reboot after update (by Jeffrey on 2025-11-10 15:05:29 GMT from Austria)
> Rebooting after updates is technical the right thing to do (TM).
This is misleading at best, but definitely not true as-is. Only parts of the system that can't live-update need to be restarted, and if an update only carries configuration updates, you usually don't even need a service restart, only a config-reload (SIGHUP reload-config or whatever else).
> Asking for a reboot after a software update is IMHO the right thing to do
I'd agree, but you just moved the goalpost. Not to mention, `needrestart (1)` does exactly that, plus it offers you the choice of which (if any) of the services in need of a restart should be restarted. It can be automated, in Debian-based distros it integrates in the update methods (CLI or graphical), and you can run it manually as an administrator.
34 • @15 (by kc1di on 2025-11-10 19:46:36 GMT from United States)
I too used Mepis back in the day and MX25 is a good release well thought out and works fine for with the KDE DE. And I've use many distros over the years. MX is amoung my favorites.
35 • Rust implementation re: Apt (by Dan G on 2025-11-10 21:29:14 GMT from United States)
I thought the threat to developers that they would either put Rust hooks in their packages within 6 months or sunset their projects was such a nice touch (sarcasm).
It feels like the developer is trying to force the distribution as a whole, to switch to Rust (a new language that hasn't even been fully implemented, standardized, widely utilized, or even allowed in the kernel yet) by rewriting the one official package management app that literally is the lifeblood of the distribution in it, saying that all of the other packages will work with it or else they won't be able to be in the distribution. That sounds like crap.
The maintainer needs to make Apt so that it is compliant with the other software languages out there, or debian needs to provide an alternative to Apt that will make the need for it go away.
36 • Fedora 43 (by Wef on 2025-11-10 21:38:38 GMT from Australia)
About a year ago I finally tired of the endless 6-monthly re-installation chore with Fedora after something like 20 years of it: update the OS, reboot, specify the new version, wait for the 2-Gb download, reboot, look through the system for changed config files, diff and merge them, maybe reboot yet again. Then rinse and repeat for every system in the house. And then there was the growing corporatisation and enshitification of stuff. I jumped to Voidlinux on all my machines and now it's a simple and occasional update when I feel like it. No need to reboot unless I really need the new kernel. Joy! And no systemd.
37 • @36 (by wef on 2025-11-10 21:46:02 GMT from Australia)
oh and I forgot - the voidlinux package management (xbps) is so fast. It makes fedora's rpm look like a snail by comparison.
38 • New Fedora installer (by bsduck on 2025-11-10 23:02:40 GMT from Switzerland)
Jesse, there actually is an advanced partitioning tool in the new Fedora installer, but it's so well hidden that I'm not surprised you didn't find it. It can be launched from the three-dot menu on the top right edge of the installer.
39 • Alternatives to Apt-Rust (by Carl on 2025-11-11 01:22:37 GMT from United States)
Pixi.sh maybe Debian should adopt rather than rewriting apt. Pixi is written in Rust. My only quibble is Pixi's constant re-downloading of the remote index for seemingly every command. Pixi assumes super-fast Internet speeds.
The Rust ecosystem still lacks polish. Most Rust things lack man pages and shell completion files. Typical CMake setups include such targets. I suppose Rust stuff will get there. A lot of GitHub issues are just "Add man pages" or "Follow XDG standards."
Dependency constraint tracking seems better suited to a logic language like Mercury. A package manager in Mercury would be 10x fewer lines of code than Rust and run 75% as fast.
Even Julia language might work. It has a native packaging tool and very high-speed performance by design.
Void Linux I use and love. Yes the xbps suite is fast, but it's C language, and not much developed any more, like Pacman from Arch Linux, which always rejected improvement ideas. Void's xbps-query is confusing. It has taken third parties to develop GUI screens (fuzzypkg is handy). Sometimes I've had corrupt indices for whatever network reasons, and had to rm -rf /var/db/xbps/http* then resync. No error messages told me how or where to fix the problem. Another gotcha is autodeletion. If your network drops while downloading a Void package, then a partial package won't match its corresponding sig file, and proceeding to install phase, xbps deletes the partial file without asking. So I wrote a workaround script. If a download breaks, I restart the script. When it's done, I can install everything.
Recently a kernel failed to work over ZFS stuff I had deleted. Dracut could not emit an initramfs. Dracut reported the error, but xbps-install did not scan its return code. Upon reboot, the system hung in outer space with not even a "blue-screen" message, lacking an initramfs to load. The cause was ZFS package removal not removing a ZFS dracut config or at least checking dracut's return code. Overall, xbps has sharp burrs that the average user, and even developers may find frustrating. These could be polished.
40 • Which flavour of Fedora is your favourite? (by Just4fun on 2025-11-11 02:05:31 GMT from Sweden)
None!
Which was not (as usual) among the answer options
41 • Debian apt rust - Julian Klode (by Rally on 2025-11-11 02:38:25 GMT from Thailand)
In the Debian mailing list there is one answer to Julian Klodes announcement with that I agree 100%:
"I find this particular wording rather unpleasant and very unusual to
what I'm used to from Debian in the past. I have to admit that I'm a
bit disappointed that such a confrontational approach has been chosen.
Thanks,
Adrian"
42 • @29 Memory safety (by Keith S on 2025-11-11 03:32:25 GMT from United States)
Yes, there is a cost to writing code in C that is memory safe, but when I said "well-written," I was basically referring to something like OpenBSD source code, which has been fuzzed, analyzed, tested, attacked, and refined for 30 years. I have more confidence in the safety of that code than almost any other, regardless of language, unless the assertion is that Rust (or Java or other languages that claim memory safety) are incapable of coding errors that lead to vulnerabilities. Rust has a much smaller and less experienced base of developers, so guardrails for memory errors does not mean error-free. That was my only point. As others have mentioned, six months is a pretty short window for, what, 60,000 packages in the Debian repos? The approach is probably meant to drive laggards to the designated language that is believed to eliminate all vulns, but it is more than a little ham-handed and does not inspire trust.
43 • NOT user of Fedora (by Ano Sixtynine on 2025-11-11 08:47:18 GMT from Bulgaria)
There should be an option "I do not use FEDORA" in the pool.
This will give additional feedback on Fedora's popularity.
44 • @39 Alternatives to Apt-Rust (by picamanic on 2025-11-11 10:58:03 GMT from United Kingdom)
@39 Alternatives to Apt-Rust: I agree with what you say about Rust: Apt and its parent Dpkg have been around for 25-30 years. I cannot understand this constant need for active development of software that has become stable and useful: if obscure bugs are discovered, they can be fixed. Rewriting Apt in Rust would be, in my opinion, be a monumental waste of time and resources, and dangerous, despite Rusts memory safety.
For new projects, modern languages like Zig or Julia might be better. I only write small programs these days, and prefer C over C++, or anything more exotic.
I have used "stock" Void Linux and XBPS for many years on an unreliable 600kbyte/s ADSL connection, and have not encountered the serious problems you describe. Maybe your use ZFS has made the file system less reliable than simpler, more mature file systems [I only use ext2!].
45 • Fedora poll (by Alan on 2025-11-11 14:02:30 GMT from United Kingdom)
Having read and re-read this weeks poll, I simply ignored it. As I never use Fedora, I understood that it wasn't aimed at users like myself.
Maybe people are feeling left out if the weekly poll questions don't apply to them?
46 • Rust solve a license problem (by LinuxBackdoor on 2025-11-11 14:08:49 GMT from Argentina)
Rust coreutils implementation only solve a license issue from GNU Coreutils.
Again it's a violation to core freedoms from this evil companies/employees.
47 • My Fedora 43 experience (but will be brief) (by Kevin Alexander on 2025-11-11 14:42:03 GMT from United States)
I tried Fedora 43 after it came out but I chose the Fedora Everything iso. I have come to do this with Fedora and its last couple versions for the last few times I've installed and tried it out. With Fedora 43 Everything, there is NO new installer. It still installed with Anaconda (which was fine by me). I have installed Fedora enough times I breeze through Anaconda quite fast including customizing my petitions. So I personally do not mind Anaconda at all. Plus the Everything ISO really allows the maximum software customizing in my opinion, regardless of desktop. Now, lastly one thing that keeps me from sticking with Fedora is that ever since Fedora 42, the program Dnfdragora behaves differently. Specifically, it requires wildcard (i.e. the * symbol) in the front or behind a package name if you don't know the exact wording for a package but at least know some or most of just any of the keywords. It used to be I could just type "Libre" and it would list everything with those letters in its software name. If you do that since version 42, it will return no results. Thus you instead must type the wildcard * so Libre* will then list all the results. And the same for knowing the back half of the title and needing to put the * in the front of the partial or only word you know of the software for it to list it. Never before did you have to do this and Dnfdragora was and can be a great GUI for software, instead of Discover. So I just end up abandoning it and prefer openSUSE nowadays. And even openSUSE has the new Merlyn software GUI and it is just as good as YaST Software so that's good of them to retain that user friendly element. Thank you and have a great day.
48 • @42 Rust and APT (by Eric on 2025-11-11 16:07:41 GMT from Germany)
> As others have mentioned, six months is a pretty short window for, what, 60,000 packages in the Debian repos?
These 60000 packages are unaffected by the upcoming changes. The issue lies in availability of the Rust toolchain for obsolete hardware architectures.
> In particular, our code to parse .deb, .ar, .tar, and the HTTP signature verification code would strongly benefit from memory safe languages and a stronger approach to unit testing.
I agree with this APT developer, but these parts seem not to be particularly performance-critical. They could be rewritten in Python without all this controversy.
> OpenBSD source code, which has been fuzzed, analyzed, tested, attacked, and refined for 30 years. I have more confidence in the safety of that code than almost any other, regardless of language
I agree, but have a look at https://security-tracker.debian.org/tracker/CVE-2024-6387. There is no strong guarantee unless formal verification methods are used.
49 • @44 APT and Dpkg (by Eric on 2025-11-11 16:17:43 GMT from Sweden)
> Apt and its parent Dpkg have been around for 25-30 years. I cannot understand this constant need for active development of software that has become stable and useful: if obscure bugs are discovered, they can be fixed.
I would appreciate if Debian dropped them in favour of Guix or something conceptually similar but I'm afraid that this is not going to happen in the next 30 years.
50 • Rust and APT (by Eric on 2025-11-11 19:06:36 GMT from Sweden)
By the way, Fedora adopted Rust-based GPG parsing in RPM over 2 years ago, in version 38.
51 • It's Impossible (by MattE on 2025-11-11 19:10:10 GMT from United States)
With 40,000,000 lines of code, bug free is statistically impractical. Sorting through all the possible bugs would more than a million year code freeze. Just like with modern CPUs with over 5 billion transistors, it is practically impossible to check every permutation. It all boils down to releasing with an acceptable level of risk.
BTW: If Bureau 121 wants to waste time hacking our little networked homes, they could do it in minutes. Be thankful we're small potatoes. Welcome to the internet.
52 • @48 OpenSSH vuln (by Keith S on 2025-11-11 19:15:06 GMT from United States)
Yes, that was potentially a dangerous vulnerability, but it did not affect OpenBSD (or Windows for that matter). It was a problem on Linux systems because of their implementation of OpenSSH. No code is perfect, but knowing that does not seem to create a real sense of caution leasing to sane (but possibly inconvenient) defaults in the Linux world.
53 • Fedora and poll (by Bobbie Sellers on 2025-11-11 19:25:12 GMT from United States)
Fedora is not my favorite distribution by any means.
There wes no choice in the voting that reflected my choice.
From the review I see many reasons to maintain my distance.
I looked at Fedora when I was starting out and it did not have ready
access to the tools i need to get on line then. I tried out a lot of
other distributions.
On the advice of a friend 20 years ago I took up with Mandriva the successor to
Mandrake and stuck with it until it would not run on my computer of the time. No
useful advice online for a user who paid for the distribution.
Then I looked for an acceptable fork and found it.
I do not care for systemd nor for Wayland which is adopted before it is
capable of replacing all the functions of X. I would hate to use a
distribution which made it the mandatory default.
bliss- Dell Precision 7730- PCLOS 2025.10 Linux 6.12.57-pclos1- KDE Plasma 6.5.2
54 • Rust (by Keith S on 2025-11-11 19:49:28 GMT from United States)
I promise this will be my last comment on the subject this week: if Rust is the cure-all for memory safety, and that is what drives the failed effort to include Rust in the kernel and now the rewriting of APT and coreutils and other key bits of the Linux infrastructure, why is there no discussion of rewriting systemd in Rust? As Dan G and Carl and picamanic have already pointed out above, there are probably better alternatives to Rust for rewriting APT, and doing so seems like a waste of effort and resources. Why not deal with systemd first, since it is written entirely in C and touches so many different parts of the system?
55 • Rust (by Jesse on 2025-11-11 20:06:08 GMT from Canada)
@54: " Why not deal with systemd first, since it is written entirely in C and touches so many different parts of the system?"
This shows a common misunderstanding of how open source development works, as opposed to commercial software development.
There is no central authority determining which projects are worthy or have priority. There is no one who decides what to "deal with" first.
Work doesn't get done, projects don't get rewritten, based on what makes sense from a big picture perspective. That's not a thing in open source - it doesn't exist.
Each project (the kernel, APT, systemd, etc) each has it own, separate, independent development team. Those individual developers decide what they want to work on and when and in what language.
If no one in the systemd project wants to write their code in Rust, then systemd will not be written in Rust. If one of the developers of APT wants to write in Rust, then their project will be written in Rust. (Or parts of it will.)
None of these projects answers to a central authority which determines which components will use which languages.
56 • which Fedora (by IPCop son on 2025-11-11 22:16:01 GMT from United Kingdom)
Fedora Security Lab is improving - it has SElinux running OTB in live mode (via ventoy) to stop pesky intruders. Nice to see, since most security distros want you to install before all security software is working.
57 • reboot required on Debian (by Cranky on 2025-11-12 17:48:40 GMT from Canada)
for those that may not know, on Debian if a reboot is required after an update, a file called reboot-required will appear magically in /run (or look in symlinked /var/run).
58 • reboot after update? (by David on 2025-11-13 01:23:19 GMT from United States)
Yes, Debian (Gnome) says "Reboot and Update" or words to that effect.
Siduction suggests/requires dropping out of init 5 (GUI) to update.
Fedora has a CLI alternative: dnf update. No reboot is required. But if the GUI update method is used, then the user will be prompted to reboot.
All of these situations suggest to me that there is some reason that a reboot is prudent even if it is not required.
59 • Reboot (by Jese on 2025-11-13 01:28:49 GMT from Canada)
@58: "Yes, Debian (Gnome) says "Reboot and Update" or words to that effect."
That's because GNOME is following Fedora's approach. If you use any other package manager (graphical or command line) on Debian it will not suggest a reboot.
"Siduction suggests/requires dropping out of init 5 (GUI) to update."
This has nothing to do with rebooting. Switching from runlevel 5 to runlevel 3 switches from desktop mode to command line. It prevents graphical libraries/desktop components from running into conflicts during the update. You can switch back to runlevel 5 after the update without a reboot.
"ll of these situations suggest to me that there is some reason that a reboot is prudent even if it is not required."
It is neither prudent or required.
60 • Which flavor of Fedora is my favorite? (by Fedora? Fed-d-d-d-d-d-deported on 2025-11-14 04:13:27 GMT from United States)
Springdale Linux? Miracle Linux? Qubes OS? OK, definitely not Qubes anymore since... "the incident". LOL.
61 • Which flavor of Fedora is my favorite? (by Broderick on 2025-11-14 13:43:57 GMT from Italy)
I use Fedora LXDE spin: less is better. X11 works well (for now).
62 • favourite fedora version (by rhtoras on 2025-11-14 15:54:25 GMT from Greece)
Well NONE. Ask poettering... he knows...
63 • Rebooting after updates (by Eric on 2025-11-14 16:20:46 GMT from Sweden)
https://freedesktop.org/wiki/Software/systemd/SystemUpdates/ - this change was introduced in Fedora 18 in 2013: https://fedoraproject.org/wiki/Releases/18/FeatureList.
64 • Rebooting after updates (by Eric on 2025-11-14 16:56:10 GMT from United States)
The proposed rationale and discussion: https://blogs.gnome.org/hughsie/2012/06/04/offline-os-updates-looking-forward-to-gnome-3-6/.
65 • @62 (by Keith S on 2025-11-14 17:31:36 GMT from United States)
Poettering is now at Microsoft, so he can know a lot more about us than which Fedora we prefer.
66 • Reboot after updates (by Eric on 2025-11-14 18:03:44 GMT from Sweden)
According to https://docs.fedoraproject.org/en-US/kde/offlineupdates/, it is possible to disable this behaviour in KDE System Settings.
67 • Benevloent Dictators for Life (BDFLs) (by Carl on 2025-11-14 21:21:06 GMT from United States)
This term emerged as open source slang. BDFLs exercise veto powers at minimum. Other projects have governance boards, plebiscites, etc. So, devs don't do what they want in all cases.
DW discussions need not influence developers. Articles and comments carry their own value. I learn from experiences, opinions, and distro evals. That said, DW may inspire some not yet developing to start or join projects.
Debian markets itself as stable. The apt rewrite I learned from DW. The value to me is knowing not to use Debian for some years. Rust is a systems language like C, more suited for kernel code. I expect apt-next will take 2-4 years to stabilize, as early systemd did.
Number of Comments: 67
Display mode: DWW Only • Comments Only • Both DWW and Comments
| | |
| TUXEDO |
TUXEDO Computers - Linux Hardware in a tailor made suite
Choose from a wide range of laptops and PCs in various sizes and shapes at TUXEDOComputers.com. Every machine comes pre-installed and ready-to-run with Linux. Full 24 months of warranty and lifetime support included!
Learn more about our full service package and all benefits from buying at TUXEDO.
|
| *NEW* NovaCustom |
NovaCustom PrivacyGuard Laptops - Escape from Big Tech
The NovaCustom PrivacyGuard Laptop is ideal for anyone who prioritizes privacy. Comes with Dasharo coreboot open source firmware and Zorin OS Pro, free from influence of Big Tech.
|
| Archives |
| • Issue 1172 (2026-05-11): Fedora 44, dealing with extra fonts, Fedora plans to provide AI tools, problems with Ubuntu's new coreutils, TrueNAS extends its development cycle, postmarktetOS improves the boot splash screen, Redox ports tmux |
| • Issue 1171 (2026-05-04): Xubuntu 26.04, extending memory with VRAM, Ubuntu plans AI features, Devuan developer forks GTK2, Mint introduces hardware enablement builds, Linux running on a PlayStation 5, local kernel exploit found in Linux |
| • Issue 1170 (2026-04-27): ENux 5.2.1, picking a second distro, AlmaLinux expands CPU support, FreeBSD publishes Status Report, Ubuntu MATE skips 26.04 release |
| • Issue 1169 (2026-04-20): Lakka 6.1, free software and source-based distributions, FreeBSD Foundation publishes compatible laptop list, Debian holds Project Leader election, Haiku progresses ARM64 port, Mint to extend development cycle, Linux 7.0 released |
| • Issue 1168 (2026-04-13): pearOS 2026.03, EndeavourOS 2026.03.06, which distros are adopting age verification, Arch adjusts its firewall packages, Linux dropping i486 support, Red Hat extends its release cycle, Debian's APT introduces rollbacks, Redox improves its scheduler |
| • Issue 1167 (2026-04-06): Origami Linux 2026.03, answering questions for Linux newcomers, Ubuntu MATE seeking new contributors, Ubuntu software centre is expanding Deb support, FreeBSD fixes forum exploit, openSUSE 15 Leap nears its end of life |
| • Issue 1166 (2026-03-30): NetBSD jails, publishing software for Linux, Ubuntu joins Rust Foundation, Canonical plans to trim GRUB features, Peppermint works on new utilities, PINE64 shows off open hardware capabilities |
| • Issue 1165 (2026-03-23): Argent Linux 1.5.3, disk space required by Linux, Manjaro team goes on strike, AlmaLinux improves NVIDIA driver support and builds RISC-V packages, systemd introduces age tracking |
| • Issue 1164 (2026-03-16): d77void, age verification laws and Linux, SUSE may be for sale, TrueNAS takes its build system private, Debian publishes updated Trixie media, MidnightBSD and System76 respond to age verification laws |
| • Issue 1163 (2026-03-09): KaOS 2026.02, TinyCore 17.0, NuTyX 26.02.2, Would one big collection of packages help?, Guix offers 64-bit Hurd options, Linux communities discuss age delcaration laws, Mint unveils new screensaver for Cinnamon, Redox ports new COSMIC features |
| • Issue 1162 (2026-03-02): AerynOS 2026.01, anti-virus and firewall tools, Manjaro fixes website certificate, Ubuntu splits firmware package, jails for NetBSD, extended support for some Linux kernel releases, Murena creating a map app |
| • Issue 1161 (2026-02-23): The Guix package manager, quick Q&As, Gentoo migrating its mirrors, Fedora considers more informative kernel panic screens, GhostBSD testing alternative X11 implementation, Asahi makes progress with Apple M3, NetBSD userland ported, FreeBSD improves web-based system management |
| • Issue 1160 (2026-02-16): Noid and AgarimOS, command line tips, KDE Linux introduces delta updates, Redox OS hits development milestone, Linux Mint develops a desktop-neutral account manager, sudo developer seeks sponsorship |
| • Issue 1159 (2026-02-09): Sharing files on a network, isolating processes on Linux, LFS to focus on systemd, openSUSE polishes atomic updates, NetBSD not likely to adopt Rust code, COSMIC roadmap |
| • Issue 1158 (2026-02-02): Manjaro 26.0, fastest filesystem, postmarketOS progress report, Xfce begins developing its own Wayland window manager, Bazzite founder interviewed |
| • Issue 1157 (2026-01-26): Setting up a home server, what happened to convergence, malicious software entering the Snap store, postmarketOS automates hardware tests, KDE's login manager works with systemd only |
| • Issue 1156 (2026-01-19): Chimera Linux's new installer, using the DistroWatch Torrent Corner, new package tools for Arch, Haiku improves EFI support, Redcore streamlines branches, Synex introduces install-time ZFS options |
| • Issue 1155 (2026-01-12): MenuetOS, CDE on Sparky, iDeal OS 2025.12.07, recommended flavour of BSD, Debian seeks new Data Protection Team, Ubuntu 25.04 nears its end of life, Google limits Android source code releases, Fedora plans to replace SDDM, Budgie migrates to Wayland |
| • Issue 1154 (2026-01-05): postmarketOS 25.06/25.12, switching to Linux and educational resources, FreeBSD improving laptop support, Unix v4 available for download, new X11 server in development, CachyOS team plans server edtion |
| • Issue 1153 (2025-12-22): Best projects of 2025, is software ever truly finished?, Firefox to adopt AI components, Asahi works on improving the install experience, Mageia presents plans for version 10 |
| • Issue 1152 (2025-12-15): OpenBSD 7.8, filtering websites, Jolla working on a Linux phone, Germany saves money with Linux, Ubuntu to package AMD tools, Fedora demonstrates AI troubleshooting, Haiku packages Go language |
| • Issue 1151 (2025-12-08): FreeBSD 15.0, fun command line tricks, Canonical presents plans for Ubutnu 26.04, SparkyLinux updates CDE packages, Redox OS gets modesetting driver |
| • Issue 1150 (2025-12-01): Gnoppix 25_10, exploring if distributions matter, openSUSE updates tumbleweed's boot loader, Fedora plans better handling of broken packages, Plasma to become Wayland-only, FreeBSD publishes status report |
| • Issue 1149 (2025-11-24): MX Linux 25, why are video drivers special, systemd experiments with musl, Debian Libre Live publishes new media, Xubuntu reviews website hack |
| • Issue 1148 (2025-11-17): Zorin OS 18, deleting a file with an unusual name, NetBSD experiments with sandboxing, postmarketOS unifies its documentation, OpenBSD refines upgrades, Canonical offers 15 years of support for Ubuntu |
| • Issue 1147 (2025-11-10): Fedora 43, the size and stability of the Linux kernel, Debian introducing Rust to APT, Redox ports web engine, Kubuntu website off-line, Mint creates new troubleshooting tools, FreeBSD improves reproducible builds, Flatpak development resumes |
| • Issue 1146 (2025-11-03): StartOS 0.4.0, testing piped commands, Ubuntu Unity seeks help, Canonical offers Ubuntu credentials, Red Hat partners with NVIDIA, SUSE to bundle AI agent with SLE 16 |
| • Issue 1145 (2025-10-27): Linux Mint 7 "LMDE", advice for new Linux users, AlmaLinux to offer Btrfs, KDE launches Plasma 6.5, Fedora accepts contributions written by AI, Ubuntu 25.10 fails to install automatic updates |
| • Issue 1144 (2025-10-20): Kubuntu 25.10, creating and restoring encrypted backups, Fedora team debates AI, FSF plans free software for phones, ReactOS addresses newer drivers, Xubuntu reacts to website attack |
| • Issue 1143 (2025-10-13): openSUSE 16.0 Leap, safest source for new applications, Redox introduces performance improvements, TrueNAS Connect available for testing, Flatpaks do not work on Ubuntu 25.10, Kamarada plans to switch its base, Solus enters new epoch, Frugalware discontinued |
| • Issue 1142 (2025-10-06): Linux Kamarada 15.6, managing ZIP files with SQLite, F-Droid warns of impact of Android lockdown, Alpine moves ahead with merged /usr, Cinnamon gets a redesigned application menu |
| • Issue 1141 (2025-09-29): KDE Linux and GNOME OS, finding mobile flavours of Linux, Murena to offer phones with kill switches, Redox OS running on a smartphone, Artix drops GNOME |
| • Issue 1140 (2025-09-22): NetBSD 10.1, avoiding AI services, AlmaLinux enables CRB repository, Haiku improves disk access performance, Mageia addresses service outage, GNOME 49 released, Linux introduces multikernel support |
| • Issue 1139 (2025-09-15): EasyOS 7.0, Linux and central authority, FreeBSD running Plasma 6 on Wayland, GNOME restores X11 support temporarily, openSUSE dropping BCacheFS in new kernels |
| • Issue 1138 (2025-09-08): Shebang 25.8, LibreELEC 12.2.0, Debian GNU/Hurd 2025, the importance of software updates, AerynOS introduces package sets, postmarketOS encourages patching upstream, openSUSE extends Leap support, Debian refreshes Trixie media |
| • Issue 1137 (2025-09-01): Tribblix 0m37, malware scanners flagging Linux ISO files, KDE introduces first-run setup wizard, CalyxOS plans update prior to infrastructure overhaul, FreeBSD publishes status report |
| • Issue 1136 (2025-08-25): CalyxOS 6.8.20, distros for running containers, Arch Linux website under attack,illumos Cafe launched, CachyOS creates web dashboard for repositories |
| • Issue 1135 (2025-08-18): Debian 13, Proton, WINE, Wayland, and Wayback, Debian GNU/Hurd 2025, KDE gets advanced Liquid Glass, Haiku improves authentication tools |
| • Issue 1134 (2025-08-11): Rhino Linux 2025.3, thoughts on malware in the AUR, Fedora brings hammered websites back on-line, NetBSD reveals features for version 11, Ubuntu swaps some command line tools for 25.10, AlmaLinux improves NVIDIA support |
| • Issue 1133 (2025-08-04): Expirion Linux 6.0, running Plasma on Linux Mint, finding distros which support X11, Debian addresses 22 year old bug, FreeBSD discusses potential issues with pkgbase, CDE ported to OpenBSD, Btrfs corruption bug hitting Fedora users, more malware found in Arch User Repository |
| • Issue 1132 (2025-07-28): deepin 25, wars in the open source community, proposal to have Fedora enable Flathub repository, FreeBSD plans desktop install option, Wayback gets its first release |
| • Issue 1131 (2025-07-21): HeliumOS 10.0, settling on one distro, Mint plans new releases, Arch discovers malware in AUR, Plasma Bigscreen returns, Clear Linux discontinued |
| • Issue 1130 (2025-07-14): openSUSE MicroOS and RefreshOS, sharing aliases between computers, Bazzite makes Bazaar its default Flatpak store, Alpine plans Wayback release, Wayland and X11 benchmarked, Red Hat offers additional developer licenses, openSUSE seeks feedback from ARM users, Ubuntu 24.10 reaches the end of its life |
| • Issue 1129 (2025-07-07): GLF OS Omnislash, the worst Linux distro, Alpine introduces Wayback, Fedora drops plans to stop i686 support, AlmaLinux builds EPEL repository for older CPUs, Ubuntu dropping existing RISC-V device support, Rhino partners with UBports, PCLinuxOS recovering from website outage |
| • Issue 1128 (2025-06-30): AxOS 25.06, AlmaLinux OS 10.0, transferring Flaptak bundles to off-line computers, Ubuntu to boost Intel graphics performance, Fedora considers dropping i686 packages, SDesk switches from SELinux to AppArmor |
| • Issue 1127 (2025-06-23): LastOSLinux 2025-05-25, most unique Linux distro, Haiku stabilises, KDE publishes Plasma 6.4, Arch splits Plasma packages, Slackware infrastructure migrating |
| • Issue 1126 (2025-06-16): SDesk 2025.05.06, renewed interest in Ubuntu Touch, a BASIC device running NetBSD, Ubuntu dropping X11 GNOME session, GNOME increases dependency on systemd, Google holding back Pixel source code, Nitrux changing its desktop, EFF turns 35 |
| • Issue 1125 (2025-06-09): RHEL 10, distributions likely to survive a decade, Murena partners with more hardware makers, GNOME tests its own distro on real hardware, Redox ports GTK and X11, Mint provides fingerprint authentication |
| • Issue 1124 (2025-06-02): Picking up a Pico, tips for protecting privacy, Rhino tests Plasma desktop, Arch installer supports snapshots, new features from UBports, Ubuntu tests monthly snapshots |
| • Issue 1123 (2025-05-26): CRUX 3.8, preventing a laptop from sleeping, FreeBSD improves laptop support, Fedora confirms GNOME X11 session being dropped, HardenedBSD introduces Rust in userland build, KDE developing a virtual machine manager |
| • Issue 1122 (2025-05-19): GoboLinux 017.01, RHEL 10.0 and Debian 12 updates, openSUSE retires YaST, running X11 apps on Wayland |
| • Issue 1121 (2025-05-12): Bluefin 41, custom file manager actions, openSUSE joins End of 10 while dropping Deepin desktop, Fedora offers tips for building atomic distros, Ubuntu considers replacing sudo with sudo-rs |
| • Full list of all issues |
| Star Labs |
Star Labs - Laptops built for Linux.
View our range including the highly anticipated StarFighter. Available with coreboot open-source firmware and a choice of Ubuntu, elementary, Manjaro and more. Visit Star Labs for information, to buy and get support.
|
| Random Distribution | 
AbeirOS
AbeirOS is a Void-based Linux distribution featuring a vanilla KDE Plasma desktop. Its main feature is the use of the musl C library (instead of GNU's glibc library used by most Linux distributions), considered a lightweight and efficient alternative to glibc but with some compatibility challenges, more suitable for containers and embedded systems. Other than that, AbeirOS is a standard Void with the XBPS package manager and runit init system.
Status: Active
|
| TUXEDO |
TUXEDO Computers - Linux Hardware in a tailor made suite
Choose from a wide range of laptops and PCs in various sizes and shapes at TUXEDOComputers.com. Every machine comes pre-installed and ready-to-run with Linux. Full 24 months of warranty and lifetime support included!
Learn more about our full service package and all benefits from buying at TUXEDO.
|
| Star Labs |
Star Labs - Laptops built for Linux.
View our range including the highly anticipated StarFighter. Available with coreboot open-source firmware and a choice of Ubuntu, elementary, Manjaro and more. Visit Star Labs for information, to buy and get support.
|
|
• 
• 
• 
• 
• 
• 
• 
