 DistroWatch Weekly |
| DistroWatch Weekly, Issue 1115, 31 March 2025 |
|
Welcome to this year's 13th issue of DistroWatch Weekly!
When a person creates something they share a bit of their outlook on the world, often giving us a glimpse into their worst fears or highest ideals. This is true whether the creator is a painter, writer, or coder. When a developer releases a project we can see what it is they look for in their software and in the world around them. This week we begin with a look at GrapheneOS, a mobile operating system in the Android family which takes a more minimal, more precise, and more secure approach to mobile computing. Read on to learn about GrapheneOS and its unique approach to powering smartphones. Which open source mobile operating system is your favourite? Let us know in this week's Opinion Poll. Then, in our News section, we talk about MidnightBSD and openSUSE introducing key new changes to their package managers. Meanwhile, one developer has resurrected the Plank project in a new fork of the minimalist dock and the postmarketOS team outlines their goals for the year. We also report on key infrastructure projects, which strive to support privacy and security, struggle as their funding is cut. In our Questions and Answers column we talk about the rise of portable package formats and how much these formats will push aside traditional package formats such as RPM and Deb. Plus we are pleased to share the releases of the past week and list the torrents we are seeding. Finally, we thank our donors who help keep us going. We wish all of you a wonderful week and happy reading!
This week's DistroWatch Weekly is presented by TUXEDO Computers.
Content:
|
| Feature Story (By Jesse Smith) |
GrapheneOS 2025
In March I noticed that my /e/OS-powered Samsung Galaxy S9, which I'd been using as my primary mobile device for five years, was starting to show signs of shuffling off this mortal coil. It had been a great, dependable, lightweight device, but all good things come to an end. I began casting about for a replacement for my phone and eventually decided to go with an older Pixel device since I'd had a good experience with iodeOS running on a demo Pixel earlier in the year. Plus, I had noticed most open source, mobile operating systems seem to support at least one Pixel phone.
I eventually settled on a refurbished Pixel 6a which came with Google's stock Android operating system and the usual dozen or so bundled proprietary apps. Quickly, I set about looking at replacement operating systems for the device.
This is when I remembered someone had asked me to take a look at GrapheneOS, a member of the Android family with a focus on security. I think the GrapheneOS website sums up the project well:
GrapheneOS is a privacy and security focused mobile OS with Android app compatibility developed as a non-profit open source project. It's focused on the research and development of privacy and security technology including substantial improvements to sandboxing, exploit mitigations and the permission model. It was founded in 2014 and was formerly known as CopperheadOS.
GrapheneOS improves the privacy and security of the OS from the bottom up. It deploys technologies to mitigate whole classes of vulnerabilities and make exploiting the most common sources of vulnerabilities substantially more difficult. It improves the security of both the OS and the apps running on it. The app sandbox and other security boundaries are fortified. GrapheneOS tries to avoid impacting the user experience with the privacy and security features. Ideally, the features can be designed so that they're always enabled with no impact on the user experience and no additional complexity like configuration options. It's not always feasible, and GrapheneOS does add various toggles for features like the Network permission, Sensors permission, restrictions when the device is locked (USB-C / pogo pins, camera, quick tiles), etc. along with more complex user-facing privacy and security features with their own UX.
The website goes on to point out that some Google-related services (and their equivalents) are stripped away from GrapheneOS:
GrapheneOS will never include either Google Play services or another implementation of Google services like microG. It's possible to install Play services as a set of fully sandboxed apps without special privileges via our sandboxed Google Play compatibility layer. See the FAQ section for more details on our plans for filling in the gaps from not shipping Play services and Google apps.
Installing
Something else which sets GrapheneOS apart from several other mobile-focused projects, such as Murena and iodeOS, is the Graphene project does not sell devices. It also does not endorse any stores which sell GrapheneOS-powered phones. One more feature which sets it apart is the Graphene project (currently) supports Pixel devices exclusively. This was good news for me and my latest purchase, though it is a narrow focus compared to most other open source, mobile-focused distributions.
Another thing Graphene does differently is the install process. Murena has its Easy Installer but it supports a small range of supported devices only and most devices must be flashed manually. UBports and iode have desktop installers which can run on a range of platforms. GrapheneOS tries to make things one step easier and provides a web-based installer for all of its supported devices. This means if you have a fairly modern web browser, running on most modern or mainstream operating systems (Linux, Windows, and macOS are supported), you can enable Developer Mode on your Pixel device, visit the GrapheneOS Web Installer page, and it will do almost all of the work. We need to plug our phone into the computer, click four buttons on the web page, and the install process is complete. This is one of the easiest approaches to transferring an operating system onto a phone I've encountered so far and the fact we don't need to download or install any applications is a real treat.
Once the new operating system is in place we can boot into it and go through a few steps provided by a first-run wizard. We're given the chance to select our preferred language, connect to wireless networks, make up a security PIN, and confirm our timezone. Unlike some members of the Android family, GrapheneOS does not offer any subscriptions or cloud-based services so there is no request for us to sign up for an account or enter any credentials.
GrapheneOS 2025030300 -- The Info app provides links to on-line resources
(full image size: 150kB, resolution: 864x1920 pixels)
Early impressions
The first thing I noticed about GrapheneOS is its interface is dark. The background is black, the few icon launchers on the home screen are grey. It's a very empty and dark environment. The default system them for applications is set to Dark. The brightness settings are turned down too, to about a third of their potential, so even with adaptive screen brightness enabled, everything looks dim.
As I mentioned, there are very few icons on the home screen and not a lot of launchers in the application drawer we can pull up from the bottom of the display. There are around a dozen applications in total, including the phone app, text messaging, gallery, camera, Vanadium web browser, software centre, and clock. There are several items missing that I'd usually expect to see included in a mobile operating system such as a calendar, note taking tool, and virtual terminal. This soon led me to the software centre.
GrapheneOS 2025030300 -- The home screen
(full image size: 42kB, resolution: 1080x2400 pixels)
Managing applications
Since GrapheneOS doesn't ship with many applications, one of the first things I did was open the software centre (it's called App Store). Here I was a bit surprised to discover there were just eleven applications available; seven of them were already installed. Of the remaining four items there were two other app stores (Google Play and its associated services alongside the Accrescent store), a photo editing tool, and an app called Android Auto which had no description. In other words, if we want to install additional applications we need to install another software centre (or two).
GrapheneOS 2025030300 -- The App Store software centre
(full image size: 171kB, resolution: 1080x2400 pixels)
I decided to fetch the F-Droid software centre from its website. This required that I first grant permission to the default web browser to install software, then confirm I really wanted to install F-Droid, then also grant F-Droid network access, and then grant F-Droid permission to install software. From that point I could use F-Droid to install most items I wanted and install the Aurora software centre to fetch the rest anonymously from Google's Play Store. (Setting up Aurora required another round of confirming the app should have network access and permission to install additional software.)
When I was finished I had three software centres, each pulling from a different repository and sending me update notifications. This isn't ideal and a step down from Murena's approach of combining multiple software centre repositories into one app store.
Adding more functionality
It surprises people that I, as a techie person, do not use many mobile applications. At most, my phones typically have about 20 apps on them, including the unused ones provided by the vendor. I'm also not usually picky about specific brands. I want a web browser, a camera, something with which to take notes, a calendar, and the ability to text. Throw in a map application and a tool that can make OpenSSH connections and I probably won't need to install anything else for months. Part of this uncluttered approach is due to me using a desktop computer for much of my computing needs (the phone is a communication device, the desktop computer is a work tool). Another aspect is I live in Canada where we don't need banking apps (the banking websites are better), WhatsApp (SMS is free), or two-factor authentication apps (everything is authenticated through e-mail or SMS). So my mobile app requirements are minimal.
Having a small app footprint generally makes it easy to switch between platforms. Moving from UBports to Murena's /e/OS, for example, was fairly straight forward. I was able to export some application data, synchronize files between the devices, and I was ready to be productive. Similarly, moving between Murena phones was easy because almost everything synced through their cloud service and it took only a few minutes to transfer everything over. When moving to GrapheneOS however, the process took just over three hours.
GrapheneOS 2025030300 -- The Settings panel
(full image size: 174kB, resolution: 1080x2400 pixels)
Part of the delay was caused by needing to install several applications and part of it was due to GrapheneOS not having a built-in sync client. There were additional hurdles though. For example, when I did install Nextcloud (and its associated apps, like Notes) I then also had to hunt down and install dependencies like DAVx5. When I wanted to transfer SMS messages from my old phone I discovered GrapheneOS's text client doesn't have an import/export feature, which meant I had to install a third-party SMS backup utility on both phones in order to transfer my messages to the new Pixel. Once I had Nextcloud working, I also had to install a third-party calendar because GrapheneOS doesn't provide one. Throughout the process I was regularly nagged for permissions - every app wanted network permissions or file access permissions or permission to access my photos/contacts/external storage.
I received so many notifications from apps wanting permissions or updates that, on multiple occasions, the underlying OS stepped in and muted new notifications for two minutes because I was receiving such a steady barrage. It's not a great sign when one aspect of the operating system needs to protect the user from another aspect of the operating system.
Eventually, I got everything transferred from my old phone to the new one, but it was the longest, most tedious process I've experienced in setting up a new phone. It also involved either replacing existing apps due to missing functionality or installing helper apps (or enabling features) to import/export data.
GrapheneOS 2025030300 -- The app drawer once all of my applications were installed
(full image size: 281kB, resolution: 1080x2400 pixels)
Security
If it seems like I'm harping on the limited functionality GrapheneOS offers out of the box, and the steps needed to get basic features in place, there is a reason. Bear with me a moment.
GrapheneOS, much like OpenBSD, places a strong focus on security. OpenBSD has an amazing security record and is well known for its focus on maintaining a small, clean codebase. While a big part of OpenBSD's fantastic security record is its proactive approach to security, another factor is OpenBSD doesn't do much by default. It doesn't have a desktop environment, many applications, Samba network shares, printing support, a web browser, and so on. Those are all add-ons, usually third-party add-ons. Which means, to get OpenBSD to do much of anything, apart from acting as a firewall, one needs to "open the gate" and install additional software, enable features, and generally break the system's security. OpenBSD doesn't offer MAC security controls, sandbox utilities, and similar tools to protect the system once third-party software enters the picture. An important piece of its security rests largely on the user never adding functionality to the minimal system.
GrapheneOS reminds me a lot of that approach. The project's OS is amount as minimal, locked down, and secure as one can get on a smartphone - offering texting, calls, a web browser, and a camera, but little else. This gives us a light, secure base from which to start. However, as soon as we want to import SMS messages, transfer bookmarks, connect to an app store with more than four applications, or sync files with another computer, then we need to toss aside the thin wall of security and we're exposed. To get anything done we need to grant applications access, install third-party tools, and generally remove the permission restrictions in place to protect us.
As a practical example, this week was one of the only times in the past ten years I've seen an in-app advertisement on my phone. I was so accustomed to my phone (running Murena or iodeOS) automatically blocking ads and trackers, that I didn't realize I was looking at an ad banner for a moment. Then I realized that GrapheneOS doesn't block trackers or ads, I suppose because none of its limited default apps show ads. But once we install third-party items, there is nothing in place to stop them from tracking us or popping up advertisements. If we want to install our own ad blocker, that means installing yet another third-party app, granting it network access, and granting it VPN permissions. I did end up installing a few tracking blockers, but found some of them were overzealous and prevented me from accessing websites. In other words, I ended up spending another hour testing and troubleshooting functionality that I'm accustomed to just having from my Android-based phones.
Further on the subject of security, something I was surprised by is GrapheneOS will show a pop-up with data sent to/from the clipboard. This appears at the bottom of the screen for a short time after data is transferred, showing a preview of the text. This preview includes passwords. In other words, if I'm signing into a website and copy a password from my password manager then it'll appear on my home screen for a few seconds. This seems like a pretty nasty security hole and a feature I quickly moved to disable.
On a positive note, I do like that GrapheneOS has an item in the pull-down menu for performing security checks. By tapping this button we can see an overview of security settings, such as memory protection, USB access, and network enabling/disabling. The security panel helps us set unlock codes and view crash reports. There are also controls for disabling app permissions, disabling location services, and hiding the notification about clipboard access. It's good to have a central area to see and modify a range of security options and I appreciated getting to go through the options to disable anything I didn't need.
GrapheneOS 2025030300 -- The Security and Privacy panel
(full image size: 141kB, resolution: 1080x2400 pixels)
Other observations
Earlier I made a comment about GrapheneOS having some similarities to OpenBSD and another area where I think that shows up is in the documentation. The Graphene project has better documentation than most mobile projects. Open source teams working on mobile operating systems tend to be small and overworked, leading to limited, old, or confusing documentation. Graphene is a rare exception in this field where the features, limitations, and practises of the operating system are clearly presented. In fact, the whole website is cleanly and elegantly presented with lots of useful information and this is not something I can say about a lot of open source projects.
Early on I tried to run GrapheneOS without Google Play services or microG installed. This proved to be counter-productive. Several apps failed to work properly, particularly anything which involved navigation (such as maps or GPS software) and any apps which accepted payments. I ended up installing Graphene's sandboxed Google Play Services bundle and this filled in the gaps in functionality.
Conclusions
I think it's fair to say I had quite a mixture of experiences and impressions from using GrapheneOS. As I just mentioned, the documentation is quite good and the project has clear goals which it executes well. People looking for a hardened version of Android with no proprietary apps or extra bloat would be well served by GrapheneOS. I also want to say the install method through the web browser is top notch. Not only is the install process well documented, but the website makes installing GrapheneOS a four-click process (once the phone is in developer mode).
The power and ease of the installer was especially key for me. I'm no stranger to flashing custom operating systems onto phones. It's been about a dozen years since I last ran a phone with its default operating system and I've had the chance to run a wide range of mobile systems, ranging from Manjaro, to UBports, postmarketOS, Murena's /e/OS, and iodeOS. The install processes vary a lot and I've grown accustomed to several. I mention this because, after I tried GrapheneOS, I tried to install a few other open source operating systems on my Pixel.
Murena's Easy Installer documentation was missing, apparently removed from its website. When I found the Easy Installer (which is also web-based) it reported my device wasn't supported (though my Pixel 6a was featured in the list of devices /e/OS supports). I then tried the manual install instructions for Murena and it rendered the phone unable to boot. Then I tried downloading iodeOS's desktop installer. It recognized my phone and downloaded the appropriate image, but choked (both times I ran the installer) during the flash and reboot phase. In the end, I went back to GrapheneOS's website and ran its web installer again, which worked perfectly.
My point is that, while GrapheneOS provides a very minimal, very locked down, and (at times) annoyingly nag-filled experience early on, it was the only system of these three Android-based operating systems to successfully install and run. I think that is worth a lot.
I will also say that while Graphene's highly minimal, locked down approach is not ideal for me (and probably not ideal for a lot of people who want to use their phones for typical smartphone tasks), it is well suited for people who want a small feature set and strict permissions. GrapheneOS gets in the way (both of the user and potential bad actors), it keeps things minimal, it encourages a "correct" approach over a feature-filled approach (again, like OpenBSD). This platform is some extra work to setup, much like Arch Linux or Slackware, but it means we end up with just what we want on the system with no extras and no bloat.
This isn't a platform for the non-techies in your life, it's not for someone who wants to run a lot of apps. But it is well suited for people who want to start small and add extra software or features as-needed. I, for one, plan to keep running GrapheneOS for a while. I was tempted to try a few other platforms, but now that I've settled into the flow of this OS (now that everything is configured the way I want it), I'm reluctant to give it up. Plus, GrapheneOS offers five-to-seven years of support, giving me another two and a half years of updates on this device. That's pretty good for an open source, mobile platform.
* * * * *
Visitor supplied rating
GrapheneOS has a visitor supplied average rating of: 9.5/10 from 10 review(s).
Have you used GrapheneOS? You can leave your own review of the project on our ratings page.
|
| Miscellaneous News (by Jesse Smith) |
MidnightBSD updates mport package manager, a reborn Plank dock, key privacy tools lose funding, openSUSE tests parallel package downloads, postmarketOS to focus on reliability
The MidnightBSD project has announced the release of a new version of the mport package manager. Version 2.7.0 of mport includes some major changes and, as a result, is not yet being merged into the operating system. "There's a new mport package manager release. Due to its massive changes, we're not going to merge it yet into the OS. (For one thing, the build will change a lot.) It does bump the master database version. There is a new table for storing conflicts. We don't make them visible in commands, but it will help with debugging the state when a package was added. Conflict detection is done at install time using the data in the package currently."
* * * * *
The Plank project created a minimal dock implementation for Linux desktops. Plank is "meant to be the simplest dock on the planet. The goal is to provide just what a dock needs and absolutely nothing more. It is, however, a library which can be extended to create other dock programs with more advanced features." The Plank project has been dormant for a while with the last release being published in 2019.
The inactivity has resulted in a fork of the original Plank and the creation of Plank Reloaded which seeks to pick up where the original project finished. "Plank Reloaded is a fork of the original Plank project, providing a simple dock for X11 desktop environments. While development began with a focus on Cinnamon, we now actively support multiple desktop environments including MATE and Xfce. Wayland is not supported at this time." The new project's GitHub page lists the new features and improvements offered by the young fork.
* * * * *
Fans of security and privacy on the Internet, along with installing open source applications on Android, may be in for a rough time in the near future. The government of the United States has cut its funding and support for the Open Technology Fund, an organization dedicated to a freely accessible and secure Internet. The Open Technology Fund (OTF) provides backing for several key infrastructure projects, including the open source F-Droid app centre, the Let's Encrypt security certificate project, and the Tor anonymous network project. As Heise reports: "Overall, the US government invests a lot of money in open source software. Last year, Let's Encrypt received around 800,000 US dollars in funding from the OTF, the Tor network received almost 500,000 US dollars and the open-source Android app store F-Droid received 396,000 US dollars. In total, the organization currently supports around 50 projects, including the development of the free VPN client OpenVPN. According to its information, the OTF has published around 2,500 patches for open-source software and the organization promotes VPNs for around 45 million people in countries with censorship." That investment has now been halted and the OTF (along with the projects it supports) will need to find alternative sources for funds.
* * * * *
The openSUSE project is experimenting with faster package management thanks to parallel connections introduced in the Zypper package management software. "The update provides two main features: an ability to fetch packages using concurrent connections, and a simplified media backend that improves connection reuse and metadata handling. Both features are currently in an experimental phase and must be manually enabled. Before the feature is officially enabled by default, parallel package downloading can be enabled by setting an environment variable before executing a Zypper operation. This allows multiple packages to be downloaded simultaneously, improving overall speed." Details on the change along with tips for enabling parallel downloads are provided in the project's news post.
* * * * *
The postmarketOS team have outlined a series of goals for 2025. Some of the key elements include finishing the migration to systemd, creating an immutable flavour of the distribution, and improving reliability: "As our community grows, we are increasing the focus we put on planning and organizing the work we do. Therefore we have been thinking hard about priorities for this year. And as we mentioned after our FOSDEM hackathon, the greatest goal for this year is reliability. So far, the postmarketOS community has mostly been focused on functionality: Hackers bring up devices and get them to a point where various device features such as audio, calls and wi-fi are usable once or most of the time. We want to get it to always." The complete overview of priorities is available in the project's blog post.
* * * * *
These and other news stories can be found on our Headlines page.
|
| Questions and Answers (by Jesse Smith) |
The rise of portable package formats
Going-portable asks: With Flatpak becoming more popular and Ubuntu replacing traditional packages with Snaps, will Flatpak and Snap eventually replace all traditional packages?
DistroWatch answers: My short answer is: portable package formats (like Snap, Flatpak, and AppImage) will probably not replace traditional package formats (such as RPM and Deb) entirely. In fact, I'd go so far as to say it's almost a certainty they will not. With that said, it wouldn't surprise me if traditional packages are, in my life time, largely regulated to hobbyist distributions and containers.
My longer answer involves some history.
First, something we need to acknowledge is that Linux distributions are unusual, borderline unique, in the way they are developed. Almost all operating systems (besides Linux distributions) are developed as an atomic unit, they are collections of software put together by united teams. An operating system - whether it is macOS, Windows, MINIX, Haiku, or one of the BSDs - is generally put together by a team working together to make a kernel, system library, shell, command line tools, and maybe a desktop environment. This approach has been almost universal for decades. One company or organization makes a complete, functional operating system and then they release it into the world. Once in the wild, third-party developers make and package software for the operating system.
The third-party applications are usually responsible for finding a way to bundle all the parts they need, aside from what they know is included in the base operating system. Different operating systems handle third-party software in various ways, but it is almost universal that the core operating system is a separate, distinct whole unit and we can pile applications on top of it. This is true whether we're talking about FreeBSD, iOS, or FreeDOS.
Linux distributions are the exception to this pattern. They never had a united base assembled by a united team. The Linux kernel was made by one team, the low-level userland utilities by another team, the desktop environments by other teams, the system library might be made by yet another team. Linux distributions are assemblies of components produced by separate groups, some of which may never work together directly. A Linux distribution is made up of hundreds, sometimes thousands, of separate pieces and it is the job of the distribution's team to stick all the various Lego-like elements together to make a whole which acts like a traditional, unified operating system.
Managing thousands of unrelated parts is a lot of work and it's one of the reasons the Linux ecosystem has massive repositories of "official" packages handled by powerful package managers - several powerful package managers - such as DNF, APT, and Pacman. These are the glue which hold together modern Linux distributions, allowing users to install new components and swap out pieces from the giant collection of unrelated parts.
These traditional package managers, their package formats, and the giant repositories are needed to maintain the disjointed, always moving collection of parts which make up Linux distributions.
In the earlier days of Linux, maintaining a few hundred packages using what we now call "traditional packages" made sense. It was actually a benefit as it made Linux distributions flexible and new software could be made available to a distribution's users by just tossing it into the growing repositories of pieces which could be bolted onto the operating system.
The problem people eventually had to face was: traditional Linux package management does not scale well. Back when we had a few hundred packages built and maintained by a dozen distributions, the situation was quite manageable and Linux's approach was pleasantly flexible and powerful. Over time though the number of packages a distribution was expected to carry grew. Debian and Fedora each offer over 60,000 packages in their latest stable releases. The NixOS repository recently topped 120,000 packages. At the time of writing, there are 45 active, independently maintained Linux distributions. Even at a conservative guess, that means there are around 2,250,000 actively maintained Linux packages in the world, not including derivatives found in child distributions such as Ubuntu, Linux Mint, Manjaro and so on. That's a lot of packages to be maintaining separately and doesn't even touch on the issue of maintaining separate versions of a package across different versions of a distribution.
Since Linux distribution maintainers have limited resources (and commercial distributions don't want to spend more money than they need to for developers and storage space) this situation creates incentive to get off the constantly accelerating treadmill of packaging more and more software. One solution to this problem is to create and encourage the use of portable packages (AppImage, Flatpak, and Snap). This allows distribution packagers to scale back, particularly on desktop applications, and leave packaging up to upstream, third-party developers. Portable packages mean, in theory, a piece of software only needs to be packaged once or twice and it can then run on virtually every distribution in the world. Plus, the distribution maintainers don't need to package, test, or fix it. This alone could cut the 2,250,000 unique packages burden in half.
Once portable packages have been introduced, the other thing distributions can do to save themselves work is to reduce the size of the core distribution and focus on making one (relatively minimal) consistent base upon which third-party software can be installed. The idea here is to make a distribution into a minimal, technically complete operating system that won't require as much maintenance while allowing users to bolt on any third-party software they want.
In short, many Linux distributions (particularly the commercially-backed ones) are trying to become more like every other operating system in the world, at least in terms of packaging. They are trying to supply a relatively small base while third-party projects will provide portable packages.
It probably sounds like I'm describing a world where classic packages (RPM, Deb, etc) are squeezed out. Their niche is going to get smaller, stuck between the immutable bases of some distributions and the portable packages running on top of them. I think, especially on commercial distributions, traditional package formats will be used less and less.
However, I don't think traditional packages are going away entirely, for two reasons. First, even immutable distributions need some way for system administrators and developers to get work done. This is often accomplished using either traditional packages or containers. And containers are usually made from traditional packages. The end users might not be interacting much with traditional packages in the future, but the old package formats still be there, behind the scenes. Probably for decades to come. The second reason traditional packages are sticking around, at least in many distributions, is their level of efficiency.
Portable packages are large, they take a long time to download, and they use a lot of disk space. Even with deduplication efforts, portable packages are big, heavy beasts that require a framework in place to operate. They don't integrate into the host operating system well and there are still performance issues to address. This means, especially for distributions where performance or flexibility are important, traditional package formats still make sense. Anyone trying to squeeze more performance from their workstation or server, anyone looking to do embedded work, anyone craving flexibility over reliability is going to prefer traditional packages. As a result, I suspect traditional packages and package managers will be with us for a long time.
In fact, some distributions pretty much rely on the classic packaging approach as a core part of their design. Any sort of highly customized distribution, such as Arch Linux and Gentoo, are philosophically at odds with immutable bases and portable packages because the whole point of these systems is to give the user the ability to customize the operating system in detail. These projects are not pre-packaged solutions, the Android is, the goal is to give users the power to mix and match pieces as they wish. As long as we have distributions geared toward do-it-yourself computer users, we're going to need traditional packages.
* * * * *
Additional answers can be found in our Questions and Answers archive.
|
| Released Last Week |
Emmabuntus DE5-1.04
Emmabuntüs is a lightweight, Debian-based distribution. The project's latest update introduces a series of key package updates as well as a German translation of the handbook. The release announcement reports: "The Emmabuntüs Collective is pleased to announce the release on March 24, 2025, of the update of its distribution, Emmabuntüs Debian Edition 5 1.04 (32-bit and 64-bit), based on Debian 12.10 'Bookworm' and the XFCE and LXQt desktop environments. This new version of our distribution mainly concerns updates to the software included in it following the release of Debian 12.10, with the update of the excellent Debian beginner’s handbook which now includes a German version included in our distribution, as well as the addition as standard of the Debian reference manuals included in it for the following languages: English, French, German, Italian, Spanish, Portuguese and Japanese. Emmabuntüs DE 5 1.04 includes the following new features and enhancements: based on the Debian 12.10 'Bookworm' operating system; Updates - Firefox 128.8.0esr, Thunderbird 128.7.0esr, deb-get 0.4.4, Ventoy 1.1.05, CTparental 5.1.23, Warpinator 1.8.8, Boot-Repair 4ppa2081, RadioTray-NG 0.2.9, Debian beginners handbook 12.10; accessibility feature updates - Ocrizer 1.4, Elograf 0.6.0."
Zorin OS 17.3
The Zorin OS project has published an update for the Ubuntu-based distribution which seeks to make former Windows users feel at home. The project's latest release, version 17.3, expands alternatives for Windows applications and changes the default web browser from Firefox to Brave. "Tailored alternatives to more Windows apps We've greatly expanded our built-in database to detect installer files for popular Windows apps. It now supports over 150 apps, recommending even more tailored alternatives to sideloading their Windows executables. For example, when you launch the Windows installer for an app like Obsidian, Zorin OS displays a dialog that directs you to the app's native Linux version in the Software store. It also suggests the closest native alternatives to other Windows-only apps, like the built-in Document Viewer instead of Adobe Acrobat Reader. To craft the most user-friendly experience for new users, we endeavor to support the widest selection of software. This update makes it easier to run the most compatible versions of your favorite apps in Zorin OS." Additional information can be found in the release announcement.
Zorin OS 17.3 -- Running the GNOME desktop
(full image size: 2.3MB, resolution: 1920x1080 pixels)
Q4OS 5.8
Q4OS is a Debian-based distribution which is available in KDE Plasma and Trinity Desktop Environment (TDE) flavours. The project's latest update is Q4OS 5.8 which introduces fresh translations to the Calamares system installer and Flatpak support is now included in the project's Desktop Profiler tool. The project's release announcement states: "The Q4OS project is pleased to announce the eighth update of its stable edition Q4OS 5 codenamed Aquarius. The new Aquarius 5.8 series receives important security and bug fixes, the recent Debian Bookworm 12.10 updates and updated Debian stable 6.1.0-32 kernel. This release brings along a few Q4OS specific improvements, fixes and a cumulative upgrade covering all the changes since the previous stable Aquarius release. The Calamares live installer has got new translations. Desktop profiler tool now features brand new plugin for handling Flatpak applications in case Flatpak framework is enabled in the system. In addition to the new plugin the Desktop profiler capabilities have been expanded and the code has been largerly rewritten to support true multithreading."
CachyOS 250330
CachyOS is a Linux distribution based on Arch Linu which focuses on speed and security optimisations. The project's latest snapshot introduces a new boot loader, re-adds NVIDIA firmware, and automates configuring Samba shares. "The first major change is that we have added a new Bootloader. Limine is a great bootloader, which can be used for BIOS and UEFI. Limine also supports some theming like GRUB. We have also added direct Btrfs snapshot support, like it works with 'grub-btrfs'. This has been greatly tested from our side and works well. The snapshots will be enabled out of the box for all installations which are using Btrfs as a filesystem. We have added a package, called 'cachyos-samba-settings', which configures and sets up Samba support. This has been requested by our users. After discussions with NVIDIA, we have re-enabled the GSP Firmware for the closed-source kernel module. The GSP Firmware had a bunch of improvements in recent releases, and most drawbacks seem to be solved now." Additional details can be found in the project's release announcement.
* * * * *
Development, unannounced and minor bug-fix releases
|
| Torrent Corner |
Weekly Torrents
The table below provides a list of torrents DistroWatch is currently seeding. If you do not have a bittorrent client capable of handling the linked files, we suggest installing either the Transmission or KTorrent bittorrent clients.
Archives of our previously seeded torrents may be found in our Torrent Archive. We also maintain a Torrents RSS feed for people who wish to have open source torrents delivered to them. To share your own open source torrents of Linux and BSD projects, please visit our Upload Torrents page.
Torrent Corner statistics:
- Total torrents seeded: 3,184
- Total data uploaded: 46.9TB
|
| Upcoming Releases and Announcements |
|
Summary of expected upcoming releases
|
| Opinion Poll (by Jesse Smith) |
Favourite non-duopoly mobile operating system
In this week's review of GrapheneOS we talked about this security-focused mobile operating system and its minimal approach. This is one of several mobile operating systems we have talked about recently which provides alternatives to the duopoly of Apple's iOS and Google's stock Android platforms. This week we'd like to hear which alternative mobile system is your favourite. Let us know which mobile devices you are using to run these open mobile platforms in the comments.
You can see the results of our previous poll on the type of storage devices used in our readers' computers in our previous edition. All previous poll results can be found in our poll archives.
|
|
|
| Website News |
Donations and Sponsors
Each month we receive support and kindness from our readers in the form of donations. These donations help us keep the web server running, pay contributors, and keep infrastructure like our torrent seed box running. We'd like to thank our generous readers and acknowledge how much their contributions mean to us.
This month we're grateful for the $123 in contributions from the following kind souls:
| Donor |
Amount |
|---|
| J S | $50 |
| Jonathon B | $10 |
| Sam C | $10 |
| Joshua B | $7 |
| Brian59 | $5 |
| Chris S | $5 |
| Chung T | $5 |
| John B | $5 |
| Maki | $5 |
| surf3r57 | $5 |
| TaiKedz | $5 |
| J.D. L | $2 |
| PB C | $2 |
| aRubes | $1 |
| Colton D | $1 |
| Stephen M | $1 |
| Kai D | $1 |
| Lars N | $1 |
| Shasheen E | $1 |
| William E | $1 |
* * * * *
DistroWatch database summary
* * * * *
This concludes this week's issue of DistroWatch Weekly. The next instalment will be published on Monday, 7 April 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: 0, value: US$0.00) |
|
|
|
 bc1qxes3k2wq3uqzr074tkwwjmwfe63z70gwzfu4lx  lnurl1dp68gurn8ghj7ampd3kx2ar0veekzar0wd5xjtnrdakj7tnhv4kxctttdehhwm30d3h82unvwqhhxarpw3jkc7tzw4ex6cfexyfua2nr  86fA3qPTeQtNb2k1vLwEQaAp3XxkvvvXt69gSG5LGunXXikK9koPWZaRQgfFPBPWhMgXjPjccy9LA9xRFchPWQAnPvxh5Le paypal.me/distrowatchweekly • patreon.com/distrowatch |
|
| Extended Lifecycle Support by TuxCare |
|
|
| Reader Comments • Jump to last comment |
1 • GrapheneOS (by Pumpino on 2025-03-31 00:27:52 GMT from Australia)
I was recently running GrapheneOS on one of my Pixels. It was fine, and I liked being able to disable network permissions to Gboard, for example. However, one thing that annoyed me was the updates every few days and the lengthy "Verifying apps" after rebooting.
A happy medium for me is running LineageOS with NikGapps core installed. I don't log in to my Google account, and I use Aurora Store and Obtainium to download apps from the play store and opensource apps. It works well. I also only have to install LineageOS updates once per month, when it's convenient for me.
2 • Linux Packaging (by Wedge009 on 2025-03-31 00:36:21 GMT from Australia)
'Portable packages are large, they take a long time to download, and they use a lot of disk space. Even with deduplication efforts, portable packages are big, heavy beasts that require a framework in place to operate. They don't integrate into the host operating system well and there are still performance issues to address.'
I think this is a big part of why I've - to date - resisted using any of the portable packaging options. The situation reminds me of the days of 'DLL hell' in Windows systems and how the solution to that seemed to be every application provider was responsible for providing the necessary DLL dependencies - especially the _specific_ versions of them - which leads to the aforementioned bloat. While traditional packages continue to be maintained (eg I use Mozilla's .deb package of Firefox rather than Ubuntu's Snap), I appreciate the minimisation of library duplication. But if the prediction of portable packages becoming the dominant form of distribution comes to pass, I suppose I'll have to accept the duplication at some point as I did when I was still using Windows (I only jumped to Linux for my primary OS fairly recently, when Windows 7 lost mainstream support in January 2020).
3 • OpenBSD security for third party apps (by OpenBSD Hobbyist on 2025-03-31 01:18:53 GMT from United States)
The review gets it wrong in terms of the security of systems like OpenBSD and GrapheneOS when installing third party apps. Several web browsers are packaged with pledge and unveil, which run them in sandboxes. This is much more secure than the defaults on most Linux systems. Likewise, even when installing third party packages that are not protected by Pledge and Unveil, you still have added security because of the underlying protections built into the operating system. It is not fool-proof, but you are definitely better off with OpenBSD and loads of third-party packages than you would be on a default Linux system with those same packages. The same is true to GrapheneOS!
4 • GrapheneOS - my experience (by Green Red Black on 2025-03-31 03:45:48 GMT from United Kingdom)
I have been running GOS for a couple of years now, and would like to thank the developers for their impressive efforts. It has allowed me to confidently carry a mobile device - a highly-functional pocket computer suitable for many use-cases, especially off-line maps (OrganicMaps) - without too much anxiety about the eyes and tentacles of the burgeoning authoritarians and predatory abusers entrenching surveillance-capitalism.
FWIW, I am not a phone user. I do not use a network SIM card, instead wifi only.
I've never had "pop-up ads" like Jesse because I practise safe computing, only installing clean FLOSS apps from F-Droid or Izzy or similar reputable sources which I can check. Not stuff via Google.
I also heartily recommend the multiple-users feature - further separating, limiting, isolating and obfuscating - which allows per-account selections of apps and preferences, and multiple separately-sandboxed browser environments, each for a different use-case.
Yes, a bit clunky, but hopefully more effective. Privacy/security vs convenience is an age-old trade-off, and privacy/security requires a vigilant ongoing mindset. It's a process.
Yes, there are daily niggles and complaints - I wish they'd incorporate a status-bar network-monitor like LineageOS and others. And some mechanism for shared-storage between multiple users.
But the focus of GOS is a no-frills, hardened, core system. And I appreciate it.
5 • Open Technology Fund - de-funding F-Droid, Tor etc (by Green Red Black on 2025-03-31 05:39:18 GMT from United Kingdom)
This is extremely worrying. Especially F-Droid.
There are two diametrically opposed forces at play in the world. On one side, those trying to Liberate and Empower, Include and Protect, championing rich diverse robust ecosystems, variously motivated by compassion and altruism or enlightened self-interest. On the other side, too-often spearheaded by sociopaths and charismatic demagogues, the forces trying to Restrict and Ensnare, Exploit or Exclude, insatiably seeking to engineer particular monocultures, motivated variously by less-than-enlightened creed, greed, ego, fear, and sheer throwback dog-eat-dog blood-lust.
All communities and organisations truly supporting the FLOSS ecosystem - especially its tools and channels offering liberating, private and secure alternatives - represent a threat to the full-spectrum-dominance practices of those malign forces, and an offensive ideological affront to their right-wing world-view. Nearly a quarter of a century ago, the extremist Ballmer infamously called Linux a "cancer" and although this one individual might have had a Damascene moment and subsequently "seen the light," there are still too many who definitely have not.
In the Whitehouse we have someone an Aussie comedian refers to as "the Tangerine Tyrant" surrounded by dangerously tribal extremists and facilitators. Conspicuously de-funding "organisations for the Public Good" like F-Droid and Tor is not just about playing to their gallery, but also actively seeking to starve and strangle anything outside their Tech-Bros preferred monocultures.
The dystopias are materialising as we watch, helpless. Where was "The Handmaid's Tale" set?
FLOSSers don't just need to be de-Googling. Prudently, we need to be de-centralising and de-Americanising key parts of our infrastructure.
Yes, it's worrying.
6 • Portable Packages (flatpack etc.) (by Mike Cornelison on 2025-03-31 06:19:51 GMT from Germany)
You omitted the Linux equivalent of "DLL hell". Traditional packages only work on the distribution they were built on (sometimes on others if library function versions match). The libraries vary from one distro to another, and from one distro release to another. "Build once, run anywhere" is not possible. However, take a look at Windows. I have a GUI app I made for Windows NT in the 1990s. The binary executable, nearly 30 years old, still runs flawlessly on Windows 11. How does Microsoft do this? Why does Linux have such a problem? Is it because Linux developers have little regard for backwards compatibility? Would appreciate your perspective.
7 • portability (by jazzfelix on 2025-03-31 07:28:42 GMT from Germany)
@6 As I understood it: Windows tries to keep its ABI from older versions. Newer Windows versions get a new ABI and on top of that they need to provide the old ABIs. That works (mostly). There are also cases on Windows where older binaries cannot be executed any more. The same is true for Linux. The difference being you got also a userland ABI. You can run a piece of software on Linux 6.14 kernel, which was running on 1.0 kernel as long as you have no other dependencies to libraries from the userland. Jesse also makes that point somewhere in the article, that Linux is distinct regarding kernel + userland being 2 different things unlike other operating systems which are combining userland + kernel. The BSD approach by the way is different. BSD is not backwards compatible, because they do not provide the old ABI. I personally like the BSD approach, because it saves you a lot of troubles/ gives you a cleaner and smaller system. The drawback being, you need to compile your older software to produce a binary that matches the new ABI.
8 • non-duopoly mobile (by Vukota on 2025-03-31 08:03:49 GMT from Serbia)
Sorry, but my phone as a first thing needs to work reliably, be easy to use and for all intended purposes for which I may be forced to use cell phone (I have at least 10 to 15 applications like this, that I have to use periodically). Open source OSes on mobile does not provide this.
For Server, Desktop, Laptop and even Tablet use I can have more than one if it is really necessary (forced on me), but for cellphone I am being forced by different institutions and manufacturers to use one and only.
9 • SailfishOS (by Filip on 2025-03-31 08:10:23 GMT from Slovenia)
It's a bit odd that Sailfish is not in the list. Yeah, it's Europe centric but it does work elsewhere.
10 • Plank and Plank Reloaded (by Always_curious_about_FOSS on 2025-03-31 08:43:15 GMT from Germany)
Can there be ready-developed software that can still be used even if the last version was 4 or 5 years ago?
How vulnerable is a tool like Plank, which has not been further developed, to possible security gaps?
For example the Openbox Windowmanager. Its last Version is from 2015.
An other example is AbiWord. The Ubuntu Resipority says its not safe because its not mantained.
So I am using Openbox and Plank and also Abiword. They are very simple and lightweight as I like it this way.
And so some Distros offering these tools still.
Nevertheless, I would like to try out the Plank Reloaded
11 • Opinion Poll - Smartphonedistro (by Always_curious_about_FOSS on 2025-03-31 08:54:25 GMT from Germany)
The missing Point in the Poll was: "I don't have a Smartphone".
And in deed I don't own a Smartphone. Since I was able to share in the freedom of my operating system in 2014 when I changed frpm XP to Linux, as no longer willing to use a proprietary OS.
But it is becoming increasingly difficult to participate in this society without a smartphone.
Perhaps a Smartphone with Postmarked OS. I was amazed by Alpine Linux on my Laptop.
I wouldn't even know if I would be able to install it on a used smartphone myself.
12 • Which non-duopoly mobile OS do you run? (by James on 2025-03-31 10:10:10 GMT from United States)
I don't believe I have the needed skills to put a non duopoly system on my phone. Until a major carrier sells an open source system on the phone, I will have to remain with what exists.
13 • non-duopoly (by Dave Postles on 2025-03-31 10:30:41 GMT from United Kingdom)
I clicked UBPorts because it's on my tablet, but I still have a Cyanogen phone which I use. I have a Murena One which I bought by mistake since it doesn't support any UK carriers.
14 • Buold once run anywhere (by Jesse on 2025-03-31 10:48:21 GMT from Canada)
@6: " "Build once, run anywhere" is not possible. However, take a look at Windows. I have a GUI app I made for Windows NT in the 1990s. The binary executable, nearly 30 years old, still runs flawlessly on Windows 11. How does Microsoft do this? Why does Linux have such a problem?"
This is a lot of misinformation in a short paragraph.
"Build once and run anywhere" works on Linux just as it does on Windows. I have 25 year old binaries that run on Linux now the same way they did back in the Red Hat Linux 9 days.
There are two ways to do it. Either statically linking the binary or shipping the dependencies with the executable. The process is the same on Linux and Windows and works for the same reason: strict backwards compatibility at the core level.
The reason some packages don't work on newer versions (of Windows or Linux) is the developer assumed their dependencies would always be built into the OS. This results in DLL Hell on Windows or missing library errors on Linux.
15 • Phone system (by Jesse on 2025-03-31 11:22:51 GMT from Canada)
@12: "I don't believe I have the needed skills to put a non duopoly system on my phone. Until a major carrier sells an open source system on the phone, I will have to remain with what exists."
Why don't you buy a phone with the OS you want from one of the open source providers? iodeOS and Murena and Volla all sell phones with open operating systems pre-installed.
16 • Different OSses (by Frank on 2025-03-31 11:25:20 GMT from India)
Most of the entries in the non duopoly OS list here are just forks of Android with some proprietary extensions removed. Do they really qualify as independent OSses? Resurrection of the Symbian/Windows for Mobile OSses would definitely be challenging nonetheless they would be proper candidates to check the duopoly.
17 • Security (by Forest for the trees on 2025-03-31 11:30:23 GMT from Canada)
@3: "The review gets it wrong in terms of the security of systems like OpenBSD and GrapheneOS when installing third party apps. Several web browsers are packaged with pledge and unveil, which run them in sandboxes.
This is missing the bigger point, you're not seeing the forest for the trees. Most third-party software on OpenBSD is not sandboxed. On Linux it usually is. Especially if network access is involved.
"This is much more secure than the defaults on most Linux systems."
It's not, really, it's doing about the same thing. A port on OpenBSD with sandboxing has about the same protection as applications on Linux with MAC protections.
"Likewise, even when installing third party packages that are not protected by Pledge and Unveil, you still have added security because of the underlying protections built into the operating system."
Not really, no. When the security issues are in the third-party packages it doesn't really help if the underlying OS is "secure". With GrapheneOS as an example, most of its protection comes from its minimalism and hardened code. But if the user installs Uber, Spotify, and Chome on their phone, most of the practical benefits of GrapheneOS security go out the window because the normal functioning of those apps is to collect data, phone home, and leak information. Nothing the OS does can help against that.
"It is not fool-proof, but you are definitely better off with OpenBSD and loads of third-party packages than you would be on a default Linux system with those same packages."
Probably not, at least not with a Linux distribution that has SELinux or AppArmor installed.
18 • CalyxOS? (by Critter on 2025-03-31 13:42:14 GMT from United States)
I was surprised to not see CalyxOS as an alternative to the duopoly. I know several who use it. I suppose that would be covered under "other" but still...
19 • Mobbies (by Treen HQ on 2025-03-31 14:16:12 GMT from United Kingdom)
Have at least six mobiles thanks to the generosity of well-meaning friends.
Never use them. Enjoy my privacy, tend my personal data just as diligently as my garden. Tin box under the desk, peripherals aside, selection old and new 'disks', Various Linux incarnations - does all I need without wearing hole in trousers, etc.
20 • GrapheneOS (by GrapheneOS user on 2025-03-31 14:48:51 GMT from United Kingdom)
GrapheneOS is good, so good I cannot imagine using another currently available mobile OS. I use it on a Pixel 5, Pixel 8 and the Pixel Tablet.
I think Jesse's review misses discussing the two biggest benefits of using GrapheneOS (GOS):
Firstly, the documentation is superb and very accessible though the website. It is found under the Features, Useage and FAQ tabs. The forum is also a valuable source of tips on how to setup/organise your profiles and apps (use the forum search field to find the best advice from older posts).
Secondly, the use of user profiles and sandboxed Google Play Services + better granularity of enabling or disabling what an app can access. Google Play can be switched on and off at will in different proliles. Please read the documentation to understand this better.
It does take quite a while to become familiar with all the extra capabilities of GOS over Android/AOSP). In my case it was about 3 months before I had really understood how I wanted to structue my profiles and the app installs.
GrapheneOS is very clever to let you choose your own balance between no google stuff and the default
Android experience. In UI terms, the only big difference is that you can live without any GooglePlay at all or use
the GOS Sandboxed GooglePlay (with full control to disable it whenever you wish, or limit it to profiles of your
choosing).
GrapheneOS really is a beautiful thing. My tip would be to buy a cheap second hand Pixel 5, 5a, 6 or 6a then install GOS and using it just through wifi, work your way through the documentation until you are familiar with how you want to configure GOS to do what you want. Then you are ready to buy a more expensive and supported Pixel device.
21 • @5: “De-Americanising” (by SuperOscar on 2025-03-31 15:27:19 GMT from Finland)
Well put, @5! Now if never de-Americasing of everything is sorely needed. Many have already joined #BoycottUSA and sought to replace everything even reeking of the US. The trickiest part of that will be in the mobile, as both Android and iOS are in the hands of conglomerates with Trumpist ties.
22 • Favourite non-duopoly mobile operating system (by nobody on 2025-03-31 16:42:24 GMT from Germany)
Opinion Poll: Favourite non-duopoly mobile operating system:
I voted: Non of the above
Reason: Do not know any android alt.. ( Support on any smartph.? Easy Install? Ready to use ? )
23 • Flatpak vs Snap vs AppImage (by Scott Dowdle on 2025-03-31 18:54:58 GMT from United States)
Canonical us using Snap for both CLI and GUI programs. Flatpak is primarily targeting GUI applications. AppImage, so far as I know, is also primarily targeting GUI applications.
Unless that changes, the only one of the three more at risk of going mainly portable packages would be Snap.
Flatpak on Fedora, for example, is for GUI applications only... which doesn't include, so far as I know, desktop environments nor window managers... only applications. It would be nice if DEs were done via Flatpak as one could more easily switch major DE versions during the lifecycle of a supported release... which they don't typically do via package-based updates.
24 • Oooooh (by Osmo on 2025-03-31 21:57:42 GMT from Sweden)
@22 ok so this is me just saying you have a WORLD of fun ahead of you. Seriously I envy you for being at that early stage of exploration (and if you're like me, try a secondary device first, and please do not - like me - try to throw it out a window :D )
Seriously. Check them out - its a whole new world for you out there!
25 • @5 Open Technology Fund (by FledermausMann on 2025-04-01 00:08:20 GMT from Australia)
>>FLOSSers don't just need to be de-Googling. Prudently, we need to be de-centralising and de-Americanising key parts of our infrastructure.
But you are ok with American tax payers money funding these opensource projects, such as Let's Encrypt,TAILS, OpenVPN, FDroid and TOR (which already has suspicious links to the CIA in its origin).
You don't see any issue at all with the US Government funding these projects, no conflicts of interest? Having uncle Sam have an interests in these projects doesn't really sit well with me personally. Also, we don't know what conditions are imposed on these projects in order to receive funding.
Fdroid received $400,000 from the OTF
TOR received $800,000 from the OTF
Let's Encrypt received $800,000 from the OTF
I'm sure just from a financial standpoint, every penny helps these projects, however FDroid is an app store only. It does not in itself produce any software. There are also other ways to get FOSS apps; namely directly from their Github repo, or using Obtainium, or Aurora Store, IzzyonDroid or AppLounge or FossDroid or Accrescent or OpenAPK. Let me count the ways.... FDroid, though popular, is not the only choice out there.
FDroid do not release financial information, which is very odd for an opensource project. Also F-Droid Limited is a UK corporation. Yes. American tax payers funding an opaque non-US project. Who knows where that $400,000 is going?
Tails which also receives funding from the OTF is created by TOR, which also receives separate funding from the OTF. What is this money being used for and how much money are these projects receiving in total every year?
Apparently in regards to the TOR Project "recent financials they provide are for available only for partway through 2022 according to IRS records, and show that the majority of funding is by the United States government. 53.5% of all funds that Tor received as of 2022 which counts to $3.2 million was from the United States government."
I will just leave it at that. The situation regarding the OTF is not a black and white issue mainly due to the lack of financial transparency from these projects and possible conflicts of interest.
26 • @25 & @5 Open Technology Fund (by Keith S on 2025-04-01 00:52:12 GMT from United States)
I thought everyone knew that TOR is a CIA honeypot. Apparently not, though. It's a bit like those who push SELinux for security while ignoring that it is designed by the NSA. Why would you trust that?
I admit that I didn't realize that F-Droid and others were also funded by the US government. Hopefully Aurora store is not.
27 • phone OS (by Josh on 2025-04-01 05:44:37 GMT from United States)
I voted "None of the above", though I suppose I could have voted "Other".
I use a Nokia dumb phone running KaiOS. It has a basic browser, media player, and a few other smart-ish functions. But, as far as I know, it isn't tied to Spygle or Crapple. It can also be used as a wifi hotspot if I REALLY need the 'net when I'm away from home.
28 • @25 US Detox (by picamanic on 2025-04-01 06:53:08 GMT from United Kingdom)
@25: whilst the Trump regime continues to hit out at everything that is non-US with transient Tariffs and defund such obscure activities as Computer Security, a progressive removal of unnecessesary dependencies seems sensible. I am sure that the relatively small sums of money needed to support these important projects can be raised without US Government involvement.
29 • 15 • Phone system (by Jesse on 2025-03-31 11:22:51 GMT from Canada) (by James on 2025-04-01 10:05:44 GMT from United States)
I have never heard of any of them. I have never seen a vendor selling them in my area. I live in northern Wisconsin where Cell Com dominates. It's pretty much Android or Apple. Samsung or I phone. I don't like either of those and have hard time even getting a Motorola around here. I use Consumer Cellular for my carrier.
30 • SELinux and Aurora store (by Jesse on 2025-04-01 10:07:36 GMT from Canada)
@26: "It's a bit like those who push SELinux for security while ignoring that it is designed by the NSA. Why would you trust that?"
It is open source, so it doesn't matter who wrote SELinux. It has been around for 20 years and can be audited by anyone. No issues have been found with its design.
"I didn't realize that F-Droid and others were also funded by the US government. Hopefully Aurora store is not"
Pretty sure they are not, especially since they are seeking donations. https://aurorastore.org/donate/
31 • Non duopoly mobile operating systems (by penguinx86 on 2025-04-01 12:43:57 GMT from United States)
There are 2 reasons I don't use non duopoly mobile operating systems:
1) The lack of compatibility with MY smartphone hardware
2) The lack of mainstream apps that all my friends use
32 • Lack of mainstream apps (by Flavianoep on 2025-04-01 13:34:37 GMT from Brazil)
One of the problems of using a non mainstream phone operating system, apart from the lack of hardware compatibility, is lack of apps. Not only mainstream apps. Apps in general. There is an appification of services, where everything depends on an app. There is at least a solution for that, albeit not free in any sense. Jolla, a Finnish company, provides an environment called AppSupport, with which is possible to run most of Android apps.
33 • Correcting: Lack of mainstream apps (by Flavianoep on 2025-04-01 13:54:54 GMT from Brazil)
I have to correct what I said. AppSupport is not a consumer product that anyone can just buy and install, but a product to be licensed by OEMs. You must buy a Jolla phone or buy and install Sailfish OS (not sure about the last one) to get AppSupport.
34 • survey should have a choice for don't own a mobile device (by paul on 2025-04-01 14:18:50 GMT from United States)
survey should have a choice for don't own a mobile device
35 • @26 Aurora Store (by Keith S on 2025-04-01 15:28:03 GMT from United States)
Good to know that Aurora Store isn't funded by the US government. I will donate something today, along with a couple of other projects.
As for SELinux, I know it is auditable. We like to say that about all open source projects. How often does it happen though? Just a question, not doubting. I know OpenBSD gets fuzzed fairly regularly, but I don't hear much about others getting a thorough audit.
36 • @23 Flatpak, etc (by Robert on 2025-04-01 16:06:50 GMT from United States)
As I understand it, Flatpak was designed to assume running in a desktop session. Would be pretty hard to distribute a desktop environment as a flatpak though.
I do agree though - desktop environments are large, typically messy installs. If there was one thing that really should be shipped in a containerized package like Flatpak, its desktops. I kind of wonder if that would solve the persistent integration problems between apps and desktops as well.
And you are completely right that Snap is the only format with the potential to take over a distribution. No other really has the ability to package command line utilities for use without a desktop, as far as I'm aware.
37 • SailfishOS user (by Shawn on 2025-04-01 17:30:15 GMT from United States)
Been using SailfishOS as my daily driver since 2017. The Android app compatibility is the key. I don't want for any apps, and I love it's not just a reskinned/stripped down Android but actual Linux under the hood.
38 • SELINUX (by FledermausMann on 2025-04-01 22:57:37 GMT from Australia)
Aurora Store. As far as anyone can tell, this is a one man project by Rahul Kumar Patel originating out of India. Kudos to that guy for making something so powerful and helpful to the entire Android community.
Regarding SELINUX, I want to add my 2 cents here as there is some misunderstanding surrounding it as well as the security of FOSS.
Opensource software has a trust issue. In the past whenever this would be brought up, hard core believers would inevitably retort with the ol' "just look at the source code if you don't trust it" remark.
This is a valid response, if:
1) you are a programmer who knows (C, PHP, Python, Java, Perl, Assembly, Shell, Kotlin, Ruby and more) all at a proficient level to understand the source
2) if the program is not too large where you can read it in a reasonable amount of time, preferably not more than 1 week.
But this "just look at the source" fails when dealing with normal users who are not programmers and when the program is millions of lines of code large. This "look at the source" is also known as "many eyes" and is Linux's main form of code security against malware and backdoors.
How easy is it to slip a backdoor into legitimate looking code? Not too difficult. There was even the Underhanded C Contest to prove it. "The Underhanded C Contest was a programming contest to turn out code that is malicious, but passes a rigorous inspection, and looks like an honest mistake even if discovered. The contest rules define a task, and a malicious component. Entries must perform the task in a malicious manner as defined by the contest, and hide the malice. Contestants are allowed to use C-like compiled languages to make their programs."
The "many eyes" practice in Linux has failed. It failed with the NSA OpenSSL backdoor, it failed with XZ-utils and no doubt it will fail again, because there are simply not enough skilled programmers who are also security analysts looking at all the programs that comprise Linux. It is just impossible. The size of the Linux kernel and systemd for example would means that a single person would be spending months if not years analyzing code.
This brings me to SELINUX and the NSA.
The "many eyes" theory has been invalidated as mentioned due to the NSA backdoor in OpenSSL. Yes, the "trustworthy" NSA backdoor'd OpenSSL and also created SELINUX and we are supposed to blindly trust this organization that it is safe to use.
SELinux has never been audited by any trustworthy truly US-independent entity, making it nearly as untrustworthy as closed source.
The Guardian reported regarding the NSA, in one of their document releases from Snowden, that the public is flat out named as the “adversary.” Among other things, the "program" is designed to “insert vulnerabilities into commercial encryption systems”. These would be known to the NSA, but to no one else, including ordinary customers, who are tellingly referred to in the document as “adversaries”.
The NSA considers US citizens as adversaries. Think about that for a moment. Knowing this, how can anyone think that that SELINUX designed by the NSA is there to protect Linux users?
Snowden's leaked documents showed us that the NSA and GCHQ have basically gotten backdoors into various key security offerings used online, in part by controlling the standards efforts, and in part by sometimes covertly introducing security vulnerabilities into various products. They haven’t “cracked” encryption standards, but rather just found a different way in.
The NSA spends $250 million per year to “covertly” influence tech product designs. The report suggest two ways this is happening. First by infiltrating standards-bodies: Independent security experts have long suspected that the NSA has been introducing weaknesses into security standards, a fact confirmed for the first time by another secret document. It shows the agency worked covertly to get its own version of a draft security standard issued by the US National Institute of Standards and Technology approved for worldwide use in 2006.
The NSA is recruiting covert operatives within telco firms to insert vulnerabilities:
To help secure an insider advantage, GCHQ also established a Humint Operations Team (HOT). Humint, short for “human intelligence” refers to information gleaned directly from sources or undercover agents.
This GCHQ team was, according to an internal document, “responsible for identifying, recruiting and running covert agents in the global telecommunications industry.”
“This enables GCHQ to tackle some of its most challenging targets,” the report said. The efforts made by the NSA and GCHQ against encryption technologies may have negative consequences for all internet users, experts warn.”
Posit; why wouldn't the NSA, by designing SELINUX, introduce weaknesses and vulnerabilities into the code that they can exploit, seeing as this is their modus operandi?
More worrying when you take all of this into consideration, is that SELINUX is backed into the linux kernel.
Sorry for the long post but I hope this clarifies a misunderstanding people have about SELINUX and the NSA.
39 • mobile os (by hulondalo on 2025-04-01 23:02:21 GMT from Hong Kong)
i remember trying to run debian on windows mobile pda and phone long ago, inspired by montavista linux on motorola 680/680i (which i also owned) but since android came out i saw there's no need to tinker with mobile os anymore. android killed my passion for adventure. i'm perfectly willing to accept anything it throws at me - maybe because i'm older and wiser now lol
40 • GrapheneOS (by DaveB on 2025-04-02 00:43:19 GMT from Australia)
I installed it on a Pixel 6a yesterday - so opening this week's issue gave me a bit of a chuckle. However as this is the first time I have used it, I cannot comment on anything. One thing I found while installing apps was that I'd be searching for the next one, and see an install confirmation for the previous one appear briefly ... and then have to go back to the previous one to try again. Don't rush the app installs.
Be aware that I could not install it using Vivaldi - I suspect the firmware file-size may have been an issue). Chromium worked fine.
41 • GrapheneOS (by 3von on 2025-04-02 15:26:16 GMT from Canada)
Been using Graphene for a couple years now and I love that I can start minimal and open things up as needed. I feel that your conclusions are fair about this OS.
42 • @38 SeLinux, AppArmor (by Jan on 2025-04-02 16:05:24 GMT from The Netherlands)
Interesting post.
Is despite your explanation on SeLinux, for a simple user SeLinux still a security improvement?
Or is AppArmor preferable?
43 • TOR & SELinux (by Mhq on 2025-04-02 16:55:07 GMT from Italy)
"I thought everyone knew that TOR is a CIA honeypot. Apparently not, though. It's a bit like those who push SELinux for security while ignoring that it is designed by the NSA. Why would you trust that?"
I don't trust anything or anyone, I simply prefer open code to closed code.
44 • SELinux vs AppArmor (by Klaus on 2025-04-02 17:11:05 GMT from Italy)
@42
The fact that openSUSE Tumbleweed switches to SELinux by default... might already be a useful indication of which one to choose.
45 • @43 TOR and SELinux (by picamanic on 2025-04-02 18:21:04 GMT from United Kingdom)
@43 TOR and SELinux: I would distinguish between open source software like SELinux/AppArmor and services like TOR. The latter relies on the integritty of the available Exit Nodes, which can be subverted by hostile players with deep pockets. That is one of the flaws with privacy and security on the wider internet that has yet to be resolved.
46 • de Americanising (by rhtoras on 2025-04-02 18:37:15 GMT from Greece)
i agree with @5 and this is why i AM nosystemD user
degoogling is not enough...
these on my personal computer
because in a work environment you are using what they tell you to (unfortunatelly)
but that's a long story, discussed in detail on sysdfree.wordpress.com
47 • GrapheneOS (by Adam on 2025-04-02 20:57:36 GMT from Czechia)
For people who want to understand well what it offers, how it works and what is the level of advancement of the GrapheneOS system compared to others here is a great comparison:
https://eylenburg.github.io/android_comparison.htm
I am not its author, I only consider it a good job
48 • @42 (by FledermausMann on 2025-04-02 22:42:48 GMT from Australia)
>>is despite your explanation on SeLinux, for a simple user SeLinux still a security improvement? Or is AppArmor preferable?
"SELinux was originally a development project from the National Security Agency (NSA) (in 2000) and originally implemented as a loadable kernel module for Linux kernel v2.4. The NSA integrated SELinux into the Linux kernel using the Linux Security Modules (LSM) framework. Many other MAC frameworks, such as apparmor, tomoyo, and smack, utilize the LSM framework as well in order to hook into the Linux kernel."
SELinux is an implementation of flexible and fine-grained nondiscretionary access controls in the Linux kernel, originally implemented as its own particular kernel patch.
Why did SELINUX switch from a loadable module to become fully integrated into the kernel? Well, in March 2001, the NSA) gave a presentation about SELINUX at the 2.5 Linux Kernel Summit.
"In response to the NSA presentation, Linus Torvalds made a set of remarks that described a security framework he would be willing to consider for inclusion in the mainstream Linux kernel. He described a general framework that would provide a set of security hooks to control operations on kernel objects and a set of opaque security fields in kernel data structures for maintaining security attributes. This framework could then be used by loadable kernel modules to implement any desired model of security. Linus also suggested the possibility of migrating the Linux capabilities code into such a module."
Google, Yahoo!, Facebook and Microsoft are among the many companies willfully cooperating with the agency to provide “backdoor” access to their systems according to the PRISM leaks from Snowden. Why wouldn’t the NSA ask Linus to backdoor Linux? Well turns out the did sometime in 2013 or sometime prior.
Considering what the NSA is, and what they do and have done, does anyone really think that the NSA spent so much time developing SELINUX and their MAC control, to help, Linux users be protected from "hackers" and other threats?
Why did they spend so much resource on this project when they could have just switched their internal systems to OpenBSD? The did not need to develop SELINUX at all, and yet they did, and now it is integrated into the Linux kernel. And we are supposed to believe it is for our benefit.
Has SELINUX ever been code audited by a non-US based organization? I can't find any evidence of it.
You decide on the conclusion.
The only way out, is switch to BSD, or,switch to Gentoo where I have even more control over Kernel elements and not allow it in during install.
The only other real option is to
49 • Smartphone OS (by penguinx86 on 2025-04-03 01:33:07 GMT from United States)
I had a Firefox OS phone for a while. These phones were NEVER available, until they were discontinued and for sale as surplus on eBay. It wasn't a bad 'phone' but the smart capabilities were limited. The app store was discontinued by the time I could buy one. It came with an old Firefox browser that worked ok, but that was the only useful app on such a small screen.
I also remember Ubuntu Touch. I never saw any of these aveilable in stores. It was only for developers and was more like Ubuntu Don't Touch. The OS was available for download, but it would only run on a very limited number of phones. I never was able to try it out.
50 • Open Technology Fund (by FledermausMann on 2025-04-03 23:42:18 GMT from Australia)
For those lamenting funding cuts to the OTF, I think you should redirect your gaze toward the Linux Foundation, which appears to be the "real" open technology fund by proxy.
You would think that the Linux Foundation is concerned with Linux, but that is incorrect.
The linux Foundation recevied according to their 2023 financial report, a total of $$262,615,790 broken down as follows:
Membership & donations 45% ($118,213,748)
Project support 26% ($67,077,259)
Event sponsorships and registrations 19% ($49,517,576)
Training and certification 10% ($27,253,092)
Other 0.2% ($554,115)
Expenses for the Linux Foundation are shown below:
Project support 64% ($171,854,065)
Project infrastructure 9% ($22,584,890)
Training and Certification 7% ($18,570,211)
Corporate operations 6% ($17,123,359)
Event support 6% ($14,602,847)
Community tooling 5% ($13,529,484)
Linux kernel support 2% ($7,804,150)
International operations 1% ($2,960,256)
Notice that Linux Kernel Support received only 2% of all funding. Even Support, received more than the name sake of the Foundation, which it is supposed to help. 2%....$7,804,150, which is most likely Linus Torvalds paycheck tbh (edit; Torvalds receives an annual salary of $10 million from the Linux Foundation as of 2022 Money Inc article).
The Linux Foundation boasts; Serving over 1,133 open source project communities. Of which Linux Kernel makes up the smallest percentage possible. What are these open source projects and communities that the Linux Foundation finances? The categories are shown below:
Cloud, Containers, & Virtualization 25%
Networking & Edge 13%
AI, ML, Data & Analytics 12%
Web & Application Development 11%
Cross-Technology 8%
Privacy & Security 4%
IoT & Embedded 4%
Blockchain 4%
DevOps, CI/CD, & Site Reliability 3%
Open Source & Compliance
Best Practices 3%
System Administration 2%
Linux Kernel 2%
System Engineering 2%
Storage 2%
Open Hardware 1%
Safety-Critical Systems 1%
Visual Effects 1%
The Linux Foundation is the real Open Technology Fund, so don't worry so much about the OTF with their $40 million funding cuts, the Linux Foundation is much more important and serves a much broader open source community.
Posit; why is the Linux Foundation only allocating 2% of their budget to Linux? They spend more on AI and Blockchain than the Linux Kernel?
This is very strange to me and frankly doesn't make a whole lot of sense. Perhaps they should rename themselves to the "AI/Blockchain and Everything Else Foundation with a sprinkle of Linux on the side".
51 • Ubuntu Touch (by Dave Postles on 2025-04-04 11:02:51 GMT from United Kingdom)
It was available on the ZTE ohone and on the BQ Aquaris tablet from new. I still have both. Firefox OS is fine, but the build of ZTE was poor (SIM and card slots fragile). I have upgraded the BQ tablet to UBPorts.It's perfectly fine. KaiOS is the continuation of FirefoxOS as a 'feature phone' not a smart phone.
52 • Correction (by Dave Postles on 2025-04-04 11:04:30 GMT from United Kingdom)
I meant Firefox OS on the ZTE.
53 • Search, Country extra possibilities (by Jan on 2025-04-04 16:14:05 GMT from The Netherlands)
Could you add to Search-Country of origin, Europe (West/East) + Asia + Australia + America (North/South) + Africa. And add the option NOT to any country or world part.
thanks in advance.
Number of Comments: 53
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.
|
| Archives |
| • 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 |
| • Issue 1120 (2025-05-05): CachyOS 250330, what it means when a distro breaks, Kali updates repository key, Trinity receives an update, UBports tests directory encryption, Gentoo faces losing key infrastructure |
| • Issue 1119 (2025-04-28): Ubuntu MATE 25.04, what is missing from Linux, CachyOS ships OCCT, Debian enters soft freeze, Fedora discusses removing X11 session from GNOME, Murena plans business services, NetBSD on a Wii |
| • Issue 1118 (2025-04-21): Fedora 42, strange characters in Vim, Nitrux introduces new package tools, Fedora extends reproducibility efforts, PINE64 updates multiple devices running Debian |
| • Issue 1117 (2025-04-14): Shebang 25.0, EndeavourOS 2025.03.19, running applications from other distros on the desktop, Debian gets APT upgrade, Mint introduces OEM options for LMDE, postmarketOS packages GNOME 48 and COSMIC, Redox testing USB support |
| • Issue 1116 (2025-04-07): The Sense HAT, Android and mobile operating systems, FreeBSD improves on laptops, openSUSE publishes many new updates, Fedora appoints new Project Leader, UBports testing VoLTE |
| • Issue 1115 (2025-03-31): GrapheneOS 2025, the rise of portable package formats, MidnightBSD and openSUSE experiment with new package management features, Plank dock reborn, key infrastructure projects lose funding, postmarketOS to focus on reliability |
| • Issue 1114 (2025-03-24): Bazzite 41, checking which processes are writing to disk, Rocky unveils new Hardened branch, GNOME 48 released, generating images for the Raspberry Pi |
| • Issue 1113 (2025-03-17): MocaccinoOS 1.8.1, how to contribute to open source, Murena extends on-line installer, Garuda tests COSMIC edition, Ubuntu to replace coreutils with Rust alternatives, Chimera Linux drops RISC-V builds |
| • Issue 1112 (2025-03-10): Solus 4.7, distros which work with Secure Boot, UBports publishes bug fix, postmarketOS considers a new name, Debian running on Android |
| • Issue 1111 (2025-03-03): Orbitiny 0.01, the effect of Ubuntu Core Desktop, Gentoo offers disk images, elementary OS invites feature ideas, FreeBSD starts PinePhone Pro port, Mint warns of upcoming Firefox issue |
| • Issue 1110 (2025-02-24): iodeOS 6.0, learning to program, Arch retiring old repositories, openSUSE makes progress on reproducible builds, Fedora is getting more serious about open hardware, Tails changes its install instructions to offer better privacy, Murena's de-Googled tablet goes on sale |
| • Issue 1109 (2025-02-17): Rhino Linux 2025.1, MX Linux 23.5 with Xfce 4.20, replacing X.Org tools with Wayland tools, GhostBSD moving its base to FreeBSD -RELEASE, Redox stabilizes its ABI, UBports testing 24.04, Asahi changing its leadership, OBS in dispute with Fedora |
| • Issue 1108 (2025-02-10): Serpent OS 0.24.6, Aurora, sharing swap between distros, Peppermint tries Void base, GTK removinglegacy technologies, Red Hat plans more AI tools for Fedora, TrueNAS merges its editions |
| • Issue 1107 (2025-02-03): siduction 2024.1.0, timing tasks, Lomiri ported to postmarketOS, Alpine joins Open Collective, a new desktop for Linux called Orbitiny |
| • Issue 1106 (2025-01-27): Adelie Linux 1.0 Beta 6, Pop!_OS 24.04 Alpha 5, detecting whether a process is inside a virtual machine, drawing graphics to NetBSD terminal, Nix ported to FreeBSD, GhostBSD hosting desktop conference |
| • Issue 1105 (2025-01-20): CentOS 10 Stream, old Flatpak bundles in software centres, Haiku ports Iceweasel, Oracle shows off debugging tools, rsync vulnerability patched |
| • Issue 1104 (2025-01-13): DAT Linux 2.0, Silly things to do with a minimal computer, Budgie prepares Wayland only releases, SteamOS coming to third-party devices, Murena upgrades its base |
| • Issue 1103 (2025-01-06): elementary OS 8.0, filtering ads with Pi-hole, Debian testing its installer, Pop!_OS faces delays, Ubuntu Studio upgrades not working, Absolute discontinued |
| • Issue 1102 (2024-12-23): Best distros of 2024, changing a process name, Fedora to expand Btrfs support and releases Asahi Remix 41, openSUSE patches out security sandbox and donations from Bottles while ending support for Leap 15.5 |
| • Issue 1101 (2024-12-16): GhostBSD 24.10.1, sending attachments from the command line, openSUSE shows off GPU assignment tool, UBports publishes security update, Murena launches its first tablet, Xfce 4.20 released |
| • Issue 1100 (2024-12-09): Oreon 9.3, differences in speed, IPFire's new appliance, Fedora Asahi Remix gets new video drivers, openSUSE Leap Micro updated, Redox OS running Redox OS |
| • Issue 1099 (2024-12-02): AnduinOS 1.0.1, measuring RAM usage, SUSE continues rebranding efforts, UBports prepares for next major version, Murena offering non-NFC phone |
| • Issue 1098 (2024-11-25): Linux Lite 7.2, backing up specific folders, Murena and Fairphone partner in fair trade deal, Arch installer gets new text interface, Ubuntu security tool patched |
| • Issue 1097 (2024-11-18): Chimera Linux vs Chimera OS, choosing between AlmaLinux and Debian, Fedora elevates KDE spin to an edition, Fedora previews new installer, KDE testing its own distro, Qubes-style isolation coming to FreeBSD |
| • Issue 1096 (2024-11-11): Bazzite 40, Playtron OS Alpha 1, Tucana Linux 3.1, detecting Screen sessions, Redox imports COSMIC software centre, FreeBSD booting on the PinePhone Pro, LXQt supports Wayland window managers |
| • Issue 1095 (2024-11-04): Fedora 41 Kinoite, transferring applications between computers, openSUSE Tumbleweed receives multiple upgrades, Ubuntu testing compiler optimizations, Mint partners with Framework |
| • Issue 1094 (2024-10-28): DebLight OS 1, backing up crontab, AlmaLinux introduces Litten branch, openSUSE unveils refreshed look, Ubuntu turns 20
| | • Issue 1093 (2024-10-21): Kubuntu 24.10, atomic vs immutable distributions, Debian upgrading Perl packages, UBports adding VoLTE support, Android to gain native GNU/Linux application support |
| • Issue 1092 (2024-10-14): FunOS 24.04.1, a home directory inside a file, work starts of openSUSE Leap 16.0, improvements in Haiku, KDE neon upgrades its base |
| • Issue 1091 (2024-10-07): Redox OS 0.9.0, Unified package management vs universal package formats, Redox begins RISC-V port, Mint polishes interface, Qubes certifies new laptop |
| • Issue 1090 (2024-09-30): Rhino Linux 2024.2, commercial distros with alternative desktops, Valve seeks to improve Wayland performance, HardenedBSD parterns with Protectli, Tails merges with Tor Project, Quantum Leap partners with the FreeBSD Foundation |
| • Issue 1089 (2024-09-23): Expirion 6.0, openKylin 2.0, managing configuration files, the future of Linux development, fixing bugs in Haiku, Slackware packages dracut |
| • Issue 1088 (2024-09-16): PorteuX 1.6, migrating from Windows 10 to which Linux distro, making NetBSD immutable, AlmaLinux offers hardware certification, Mint updates old APT tools |
| • Issue 1087 (2024-09-09): COSMIC desktop, running cron jobs at variable times, UBports highlights new apps, HardenedBSD offers work around for FreeBSD change, Debian considers how to cull old packages, systemd ported to musl |
| • Issue 1086 (2024-09-02): Vanilla OS 2, command line tips for simple tasks, FreeBSD receives investment from STF, openSUSE Tumbleweed update can break network connections, Debian refreshes media |
| • Issue 1085 (2024-08-26): Nobara 40, OpenMandriva 24.07 "ROME", distros which include source code, FreeBSD publishes quarterly report, Microsoft updates breaks Linux in dual-boot environments |
| • Issue 1084 (2024-08-19): Liya 2.0, dual boot with encryption, Haiku introduces performance improvements, Gentoo dropping IA-64, Redcore merges major upgrade |
| • Issue 1083 (2024-08-12): TrueNAS 24.04.2 "SCALE", Linux distros for smartphones, Redox OS introduces web server, PipeWire exposes battery drain on Linux, Canonical updates kernel version policy |
| • Issue 1082 (2024-08-05): Linux Mint 22, taking snapshots of UFS on FreeBSD, openSUSE updates Tumbleweed and Aeon, Debian creates Tiny QA Tasks, Manjaro testing immutable images |
| • Issue 1081 (2024-07-29): SysLinuxOS 12.4, OpenBSD gain hardware acceleration, Slackware changes kernel naming, Mint publishes upgrade instructions |
| • Issue 1080 (2024-07-22): Running GNU/Linux on Android with Andronix, protecting network services, Solus dropping AppArmor and Snap, openSUSE Aeon Desktop gaining full disk encryption, SUSE asks openSUSE to change its branding |
| • Issue 1079 (2024-07-15): Ubuntu Core 24, hiding files on Linux, Fedora dropping X11 packages on Workstation, Red Hat phasing out GRUB, new OpenSSH vulnerability, FreeBSD speeds up release cycle, UBports testing new first-run wizard |
| • Issue 1078 (2024-07-08): Changing init software, server machines running desktop environments, OpenSSH vulnerability patched, Peppermint launches new edition, HardenedBSD updates ports |
| • Issue 1077 (2024-07-01): The Unity and Lomiri interfaces, different distros for different tasks, Ubuntu plans to run Wayland on NVIDIA cards, openSUSE updates Leap Micro, Debian releases refreshed media, UBports gaining contact synchronisation, FreeDOS celebrates its 30th anniversary |
| • Issue 1076 (2024-06-24): openSUSE 15.6, what makes Linux unique, SUSE Liberty Linux to support CentOS Linux 7, SLE receives 19 years of support, openSUSE testing Leap Micro edition |
| • Issue 1075 (2024-06-17): Redox OS, X11 and Wayland on the BSDs, AlmaLinux releases Pi build, Canonical announces RISC-V laptop with Ubuntu, key changes in systemd |
| • Issue 1074 (2024-06-10): Endless OS 6.0.0, distros with init diversity, Mint to filter unverified Flatpaks, Debian adds systemd-boot options, Redox adopts COSMIC desktop, OpenSSH gains new security features |
| • 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 | 
BunsenLabs Linux
BunsenLabs Linux is a distribution offering a light-weight and easily customizable Openbox desktop. The BunsenLabs distribution is based on Debian's Stable branch and is a community continuation of the CrunchBang Linux distribution.
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.
|
|
• 
• 
• 
• 
• 
• 
• 
