DistroWatch Weekly |
DistroWatch Weekly, Issue 1091, 7 October 2024 |
Welcome to this year's 41st issue of DistroWatch Weekly!
The open source community is a place of experimentation and innovation where anyone with an idea can craft it and share their vision with the world. Often times, this freedom leads to new approaches, faster components, new desktop environments, and better tools. Sometimes it can lead to entirely new operating systems. This week we begin with a look at Redox OS, a young operating system written in Rust and featuring a microkernel. Read on to learn more about what it is like to use the Redox operating system. Let us know what you think of Redox OS in our Opinion Poll. Then, in our News section, we share updates from the Redox project and discuss improvements coming to Linux Mint's desktop experience and the distribution's package managers. Plus we talk about the Qubes team certifying new laptop hardware for security-focused customers. Our Tips and Tricks article this week seeks to clear up the difference between portable universal packages and unified package management following some confusion about last week's poll. We are then happy to share the releases of the past week and list the torrents we are seeding. We wish you all a fantastic week and happy reading!
This week's DistroWatch Weekly is presented by TUXEDO Computers.
Content:
|
Feature Story (By Jesse Smith) |
Redox OS 0.9.0
Redox OS is one of the more recent additions to the DistroWatch database. The project is one of just one of seven active projects in the database which is not a member of the Linux, BSD, or Solaris families. Redox is an independent project which explores modern operating system designs (unlike projects such as ReactOS and Haiku which seek to continue the lives of older designs).
Redox OS uses a microkernel approach, meaning the core, privileged part of the operating system is quite small, leaving drivers and services to run in userspace. This should make the underlying operating system more secure and more stable. Redox is written in Rust, a memory-safe language, meaning the core components should also be harder to exploit due to programming errors. Furthermore, the project introduces some interesting ideas, evolving the concept of "handle everything like a file" to handling every resource like a URL.
The Redox OS project recently announced the launch of Redox OS 0.9.0. This release features several applications imported from the COSMIC desktop (which I reviewed in September), including COSMIC Files, COSMIC Editor, and COSMIC Terminal. These utilities are also written in Rust.
The announcement mentions Redox ships with a desktop environment, a few games, the Nano text editor, and a web browser. There are three editions, available in i686 and x86_64 builds: Server, Desktop, and Demo. As I understand it, Demo is basically the Desktop edition meant to be run from live media and possibly with more applications installed.
At this time Redox still lacks USB device support which means it won't work with most physical hardware (keyboards, printers, and mouse devices), but it can run in some virtual machines which side-steps the USB limitation.
The 0.9.0 release does include a package manager, named pkg, which I'll touch upon later.
Earlier, I mentioned there are three editions of Redox. The ISO and IMG files for these editions are all compressed with the zst compression method (which some Linux distributions don't support out of the box). The zst package may need to be installed before you can unpack the ISO/IMG file. These download options range in size from 67MB for the Server edition, to 115MB for the Desktop edition, and 344MB for the Demo edition. When unpacked they expand quite a bit, with the largest (the Demo edition) reaching 1.5GB when unpacked.
Since I knew Redox wouldn't be able to work with my hardware since my keyboard and mouse pointers are connected via USB, I focused on trying to run Redox in a virtual machine. The project's handbook has a section on running the operating system in various virtual environments. I set up VirtualBox with the suggested line-by-line tweaks and tried running the Demo edition. It failed to boot. I also tried the Desktop edition and it also failed to boot.
Digging further into the handbook I found there are command line instructions for setting up VirtualBox with exactly the configuration required to run Redox. This results in some different settings when compared to the graphical approach and the command line instructions worked, allowing me to boot the Demo edition.
Early impressions
The Demo edition booted to a graphical login screen where I was prompted for the password to an account called "user". The correct answer is to leave the password field blank. This signs us into the project's desktop environment.
The desktop environment is fairly simple. A panel is placed across the bottom of the display with an application menu, a few quick-launch buttons, and a clock. The application menu presents us with a list of installed applications and one sub-group, called Games. Clicking the Games button erases the menu and replaces its contents with just a list of items in the Games category. We can then launch a game or exit back up to the top-level menu. The desktop, while it includes applications from COSMIC, appears to be a custom desktop specifically made for Redox rather than an existing desktop like LXQt or Xfce.
The desktop is responsive and has no flashy distractions or special effects. It's simple and clean. The interface isn't particularly attractive, but it's easy enough to navigate.
Redox OS 0.9.0 -- Using the COSMIC file manager and text editor
(full image size: 1.1MB, resolution: 1600x1200 pixels)
Included software
Redox ships with a handful of applications. The COSMIC file manager, text editor, and terminal are included. The first two of these worked well for me. The terminal application crashed frequently, usually before I'd managed to type more than one command. I think my record was managing to type four commands in a row before the terminal crashed. Sometimes I didn't even get to type one whole command before the terminal window would disappear. This prevented me from exploring much of the underlying operating system.
Redox OS 0.9.0 -- My longest session with the virtual terminal
(full image size: 1.8MB, resolution: 1600x1200 pixels)
A related problem I ran into was most instructions in the Redox handbook rely on the terminal, making it difficult to accomplish anything when the terminal isn't working. There didn't appear to be any other desktop terminal available, or any text console the way most Linux distributions supply a terminal when we press Ctrl+Alt+F2.
There were other applications. The most impressive of the group was a functional web browser which was able to navigate to various websites, displaying text and images. The web browser doesn't have many features, but it did make it possible to look up information about Redox.
Redox OS 0.9.0 -- Using the web browser to visit Redox's website
(full image size: 2.2MB, resolution: 1600x1200 pixels)
The DOSBox emulator for games is included and it worked for me. There were a few games, including Neverball and DOOM, installed. I tried to run these, but they just displayed blank windows and, in the case of Neverball, caused the desktop to stop responding, forcing a restart. There is also a calculator that works and an application which simply displays the periodic table of elements.
Redox OS 0.9.0 -- Displaying the periodic table of elements
(full image size: 2573kB, resolution: 1600x1200 pixels)
It's not a large collection of applications, or a particularly well functioning collection. At this stage it's more of a proof of concept that shows Redox can be used to run a range of applications, including a web browser and a file manager.
Package management
Redox OS does include a package manager, called pkg. According to the documentation this package manager can fetch, install, and upgrade software on the system. There are two key features missing at this time: removing packages which have been installed, and searching for packages in a repository. As far as I can tell there is no method to find out what packages are available.
When combined with the virtual terminal's habit of crashing, this lack of search feature kept me from properly exploring pkg's functions. As with many parts of Redox, this package manager appears to be in its early stages of evolution.
Conclusions
There are a lot of experimental operating systems in the world. Most of them are small, one-person projects. They often experiment with implementing a minimal POSIX environment, demonstrate a microkernel design, or show off a bare bones desktop environment running with minimal resources. While interesting to see, those small projects rarely develop further. Most one-person projects don't attract additional developers, add a package manager, or reach a point of being properly documented.
Redox OS 0.9.0 -- The application menu
(full image size: 3.0MB, resolution: 1600x1200 pixels)
Redox OS is unusual in that it has attracted more developers, people have fleshed out its documentation, and it has added new components such as a package manager and some modern desktop elements. It's not just an interesting collection of concepts (a microkernel, Rust-based, and using modern resource path names), it actually seems to be, well, going somewhere. The project looks polished, well thought out, and there is some practical collaboration happening between Redox and COSMIC.
Despite its strong efforts over the past few years, Redox (despite all of its achievements) hasn't reached a point yet where it is practical to use on a regular basis. The key sticking point is hardware support, which is almost always an issue for any non-Linux open source operating system. Driver support is tricky, on a technical level, and expensive, and there are thousands of devices in the world to support. As I discovered, there are also limitations when it comes to using the terminal, running games, and using the package manager.
I will say the existing web browser is impressive. It really showcases what Redox can accomplish. The working file manager and text editor are also running smoothly and show off Redox's capabilities as a desktop operating system. There is still a long way to go, especially with hardware/USB support, but there is also a lot here for the Redox team to be proud of.
Redox isn't ready yet to be a daily driver, but it is worth looking at. It has some neat design concepts which could, along with its source-compatibility with Linux, make it a capable project in a few years.
* * * * *
Visitor supplied rating
Redox OS has a visitor supplied average rating of: 8.5/10 from 2 review(s).
Have you used Redox OS? You can leave your own review of the project on our ratings page.
|
Miscellaneous News (by Jesse Smith) |
Redox begins RISC-V port, Linux Mint polishes the user interface, Qubes certifies NitroPad v56 laptop
The Redox OS project has published a news update for the month of September. The project's newsletter covers fixes and porting QEMU to Redox OS. The Redox team is also starting work on a port of their operating system to the RISC-V architecture. "Andrey Turkin started the RISC-V port and sent improvements to our toolchain. Jeremy updated the QEMU patches to the latest version and is working on the remaining bugs. The hope is that QEMU will be ported soon."
* * * * *
The Linux Mint team has published their monthly newsletter for September. The newsletter covers two main points of interest. The first is a reworking of several Cinnamon elements, such as the Force Quit pop-up, volume control, and workspace switcher. These have been redesigned to look better, with a sleeker design and better contrast. The second set of changes involve upgrades to the package management tools, reducing complexity and dependencies on older utilities. "This allowed us to completely refactor the code in the Update Manager and greatly simplify its architecture. It worked well but it had been written decades ago and some of the techniques and components it relied on weren't future-proof. Its multithreading code was deprecated and hard to maintain. It depended on Synaptic and technology related to Gtk.Plug/Socket which couldn't work in Wayland. It also handled multi-processing calls and serialization itself. All of this was simplified. In the Software Sources tool, the downgrading of foreign packages was performed via a VTE (an embedded terminal). This is now handled by Aptkit directly, with a nice progress dialog."
* * * * *
The Qubes project certifies some hardware to confirm it runs properly with Qubes OS. "Qubes-certified hardware is hardware that has been certified by the Qubes developers as compatible with a specific major release of Qubes OS. All Qubes-certified devices are available for purchase with Qubes OS preinstalled." A new laptop has been added to the list of certified devices, the NitroPad v56. The NitroPad is certified to work with Qubes OS 4.2.3 and newer. Details on the laptop can be found in this Qubes news post. The NitroPad is available for purchase from the NitroKey shop.
* * * * *
These and other news stories can be found on our Headlines page.
|
Tips and Tricks (by Jesse Smith) |
Unified package management vs universal package formats
Last week we ran an opinion poll in which we asked what our readers thought about unified package managers, such as the rhino-pkg utility found in Rhino Linux.
A few of the comments, and responses through other channels, revealed that there was confusion about what a unified package manager is, particularly how it is different from a universal package format. Here are a few of the replies we received:
A unified package manager is how a certain distro family switched Firefox from Deb packages to Snaps without the users being able to keep using Debs.
* * * * *
Unified package manager is a recipe for disaster, used by lazy developers/maintainers to avoid having to repackage/support their native package format, update software and to address code review and security issues properly. I know Flatpaks/Snaps/AppImages have their own "good" sides, but it still comes down to my first conclusion.
* * * * *
Unified package manager, well it eliminates a primary choice people have to make: choosing a distro based on packages available.
This seems like a good time to clear up the misunderstandings.
First, let's talk about what a universal package format is. A universal package format (also called a portable package format) is an archive which contains both an application and the dependencies needed to run the application. This allows the software embedded inside the archive to be run on most Linux distributions without the user needing to worry about external dependencies. The idea is we should be able to fetch a universal package and install it on almost any modern Linux distribution and the software will work because everything it needs to run is bundled with it.
On the positive side, a universal package is portable (it can be shared across multiple distributions) and it should run just about anywhere without rebuilding/repackaging. This means there is no requirement for each distribution to make their own build of the application, packaging it into RPM, Deb, or other formats. Users can use one central repository, or the upstream developer's website, to fetch and install the desired software. This saves maintainers from engaging in a lot of duplicated effort.
There are negative effects to using a universal format. Universal bundles are typically quite large, since all dependencies are packed into one archive. There are also security concerns as new builds of the universal package may need to be created whenever a bundled dependency is found to have a security flaw. This is in contrast to traditional Linux package management where libraries and dependencies are shared across the system, allowing distro maintainers to fix a security flaw in one spot and have it applied across all applications on the system.
Some commonly used universal package formats include Flatpak, Snap, and AppImage. Each one has slightly different approaches, slightly different pros and cons, but they all accomplish approximately the same thing - applications which can be installed from one file and run across multiple distributions.
Next, let's look at unified package management. Typically, every type of package in the world (whether it is an RPM file, Deb archive, Flatpak bundle, or another type of package) needs a corresponding package manager to handling installing, updating and removing the software. On RPM-based distributions we usually find a tool called rpm working behind the scenes and a friendly utility called dnf being run from the command line. On Deb-based distributions people usually use apt or apt-get to manage software. Distributions in the Arch Linux family use pacman as their package manager.
In recent years it has become more common for distributions to use more than just their usual, classic package manager. Now, instead of a distribution using just DNF, APT, or pacman they also tend to support universal package formats such as Flatpak or Snap. They might also support third-party repositories, like the AUR or Pacstall.
It is inconvenient for users of these distributions to run two or three different package managers to install and update their applications. Ideally, users shouldn't need to run two or three package managers just to apply all available security updates - it's tedious and easy to forget to run each package manager separately.
To fix this problem, some projects are introducing utilities which will streamline the process. This allows the user to run a command like "rhino-pkg update" once and the rhino-pkg command finds and runs the update command of each package manager on the system. In other words, instead of the user running "sudo apt update; sudo apt upgrade; flatpak update; sudo pacstall update" and babysitting each step, the user can run one command: "rhino-pkg update".
These commands, which act as wrappers around the lower-level package managers, are called unified package managers. A unified package manager typically runs low-level, classic package managers, universal package managers, and third-party repository managers in the background.
Now, to address some of the above comments, like this one: "A unified package manager is how a certain distro family switched Firefox from Deb packages to Snaps without the users being able to keep using Debs." What Canonical did had nothing to do with unified package managers. Canonical introduced a portable package manager, Snap, onto their system. They then replaced their old Deb package with a dummy package. This meant when the user tried to install the Firefox Deb package, the Deb package launched Snap and caused Firefox to be installed as a Snap. No unified package manager was involved. Canonical just changed what the Firefox Deb package did.
"Unified package manager is a recipe for disaster, used by lazy developers/maintainers to avoid having to repackage/support their native package format." This again mixes up unified package managers with universal package formats. Universal packages allow software to be run across multiple distributions, saving the maintainers of Linux distributions work and avoiding duplication of effort. Unified package managers are not involved in this process.
"Unified package manager, well it eliminates a primary choice people have to make: choosing a distro based on packages available." Unified package managers do not affect which packages or software are available. They streamline how the user interacts with multiple package managers. The underlying software, the packages available, remain the same. A unified package manager simply reduces the number of steps a user needs to perform when searching for new software and updating installed packages.
Hopefully, this clears up the differences between unified package managers (such as rhino-pkg, mintInstall, and MX Package Installer) and universal package formats (such as Snap, Flatpak, and AppImage).
* * * * *
Additional tips can be found in our Tips and Tricks archive.
|
Released Last Week |
Manjaro Linux 24.1.0
Philip Müller has announced the release of Manjaro Linux 24.1.0, an updated build of the project's rolling-release distribution with separate GNOME, KDE Plasma and Xfce editions. The new release comes with GNOME 46.5, KDE Plasma 6.1 and Linux kernel 6.10: "Since we released 'Wynsdey' in May 2024, we worked hard to get the next release of Manjaro out there. We call it Xahea. The GNOME edition has received several updates to GNOME 46 series. This includes a lot of fixes and polish when GNOME 46 originally was released in March 2024. The Plasma edition comes with the latest Plasma 6.1 series 1 and KDE Gear 24.08 1. It brings exciting new improvements to your desktop. Plasma 6 hits its stride with version 6.1. While Plasma 6.0 was all about getting the migration to the underlying Qt 6 frameworks correct, 6.1 is where developers start implementing the features that will take your desktop to a new level." See the release announcement for further information.
Manjaro Linux 24.1.0 -- Running the Xfce desktop
(full image size: 1.1MB, resolution: 1920x1080 pixels)
* * * * *
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,083
- Total data uploaded: 45.4TB
|
Upcoming Releases and Announcements |
Summary of expected upcoming releases
|
Opinion Poll (by Jesse Smith) |
What do you think of Redox OS?
This week we began with a review of Redox OS, a modern operating system written in Rust. While Redox OS has a ways to go, especially in terms of hardware support, the project introduces some interesting concepts and useful design choices. Have you tried Redox? Let us know about your experiences in the comments.
You can see the results of our previous poll on unified package managers in our previous edition. All previous poll results can be found in our poll archives.
|
Have you tried Redox OS?
I have tried Redox and liked it: | 53 (2%) |
I have tried Redox and did not like it: | 43 (2%) |
I am currently running Redox and like it: | 2 (0%) |
I am running Redox and do not like it: | 1 (0%) |
I plan to try Redox later: | 346 (13%) |
I have no plans to try Redox: | 2250 (83%) |
|
|
Website News |
DistroWatch database summary
* * * * *
This concludes this week's issue of DistroWatch Weekly. The next instalment will be published on Monday, 14 October 2024. Past articles and reviews can be found through our Weekly Archive and Article Search pages. To contact the authors please send e-mail to:
- Jesse Smith (feedback, questions and suggestions: distribution reviews/submissions, questions and answers, tips and tricks)
- Ladislav Bodnar (feedback, questions, donations, comments)
|
|
Tip Jar |
If you've enjoyed this week's issue of DistroWatch Weekly, please consider sending us a tip. (Tips this week: 2, value: US$25) |
|
|
|
 bc1qxes3k2wq3uqzr074tkwwjmwfe63z70gwzfu4lx  lnurl1dp68gurn8ghj7ampd3kx2ar0veekzar0wd5xjtnrdakj7tnhv4kxctttdehhwm30d3h82unvwqhhxarpw3jkc7tzw4ex6cfexyfua2nr  86fA3qPTeQtNb2k1vLwEQaAp3XxkvvvXt69gSG5LGunXXikK9koPWZaRQgfFPBPWhMgXjPjccy9LA9xRFchPWQAnPvxh5Le paypal.me/distrowatchweekly • patreon.com/distrowatch |
|
Extended Lifecycle Support by TuxCare |
|
Reader Comments • Jump to last comment |
1 • Peripheral to uniersal pkg mgrs (by murfi on 2024-10-07 01:08:37 GMT from United States)
I still think there should be some distros which are statically linked. Dynamic linking largely came about due to the lack of ram/disk space. We don't have that problem now.
2 • Static linking (by Jesse on 2024-10-07 01:24:06 GMT from Canada)
@2: "Dynamic linking largely came about due to the lack of ram/disk space. We don't have that problem now."
Dynamic linking also allows one library to be fixed (or updated) and to have that fix applied to all programs which use the library. Imagine, for a moment, glibc patches a fix. Do you really want to re-install almost every package on your system every time that happens? That's what you'd face with static linking, basically re-installing your whole operating system whenever a really low-level package published a security update. I don't think you want to re-install every desktop application every time GTK or Qt patches a vulnerability either.
Imagine running a rolling release distro! Any time a commonly used library had a major update you'd end up re-installing or re-building every package.
Sure, we don't have as many limits in terms of disk or memory anymore, but a lot of people still have limits on their bandwidth and/or the time they are willing to spend updating their operating system.
3 • UNIVERSAL PACKAGE, manager, etc.... (by Greg Zeng on 2024-10-07 02:12:33 GMT from Australia)
All operating systems have these problems. In order of user popularity: Windows, Apple, Android, Linux, BSD,... ALL systems have ease of updating, adapting to existing hardware-software-settings, error detection-correction, updates, waste removal, and user notifications.
Most systems have simple or complex ways to compile from raw source code. In Linux, raw source code compiling could be hidden in GZ compression, AUR and similar script code instructions, or as script code of compiled application codes. Third-party application writers prepare ready-to-run DEB files in the form of the one Debian compilation code. An AUR script code can compile raw source code into easy DEB code.
According to MajorGeeks, the second most used Linux code favoured is any of the many incompatible forms of RPM compiled code; either the one official RPM Red Hat brand name or any of the unofficial RPM codes (SuSe, PCLOS, Mandriva, etc).
The third most popular 'universal package' chosen by independent application writers is the Ubuntu APT instructions. Of the 128 Debian-based Linux brand names, https://distrowatch.com/search.php?ostype=All&category=All&origin=All&basedon=Debian¬basedon=None&desktop=All&architecture=All&package=All&rolling=All&isosize=All&netinstall=All&language=All&defaultinit=All&status=Active#simpleresults
https://distrowatch.com/search.php?ostype=All&category=All&origin=All&basedon=Ubuntu¬basedon=None&desktop=All&architecture=All&package=All&rolling=All&isosize=All&netinstall=All&language=All&defaultinit=All&status=Active#simpleresults
there are 52+18 based on Ubuntu, which then uses this PPA system.
Also ran in the 'universal package system', in order of application writer, are Flatpak, Appimage, Snap, and Puppy. Each of these closed systems is lacking in application choices, and in staying alive to the newest updates of the raw, uncompiled codes.
Most application writers, including those specializing in Linux-only applications, often prefer to also offer the most used operating systems with their Linux-only applications. For example, Kdenlive & Shotcut video editors.
Most applications, including FreeFileSync, Slimjet & Ventoy, are hard to find in any Linux ready-to-run compiled code. Hopefully, either Flatpak or Appimage might become more used in Linux. Otherwise, Linux will stay with its 2 - 4 % popularity, of all computer operating systems.
4 • Unified package manager (by Vinfall on 2024-10-07 02:12:41 GMT from Singapore)
So what does a unified package management do exactly behind the scene? The description sounds like nothing more than a wrapper/alias for various (traditional) package managers.
I used to consider it as a universal converter which would translate different types of package (RPM/DEB/XBPS/whatever) by parsing package info & (probably via multiple params) installing it into a unified place (or better, convert every weird package format into the one used by current distro).
That's how I conclude that it is hacky and should be avoided, as usually such thing is not recommended due to the very likely brokerage & different (sometimes even contradictory) packaging guidelines.
Do things change recently and this can already done properly?
5 • @ 4 • Unified package manager (by Because; reasons on 2024-10-07 03:18:59 GMT from New Zealand)
mostly agree with your take, 'happy to be wrong and have the error of my ways corrected'.
Each of the various package managers, apart from retrieving and installing required packages, keep track of those pesky dependencies, and have an 'internal to themselves' record of installed packages.
When you have more than one, the 'internal record of installed applications' ( and dependencies) will differ, so, even by using a wrapper to invoke the required package-manager per package type is fraught with risk, to my simple mind.
If RhinoLinux have truly managed to overcome this, kudos to them.
I am aware that one .rpm distro offers 2 package managers, and recommend using one, and sticking with it for the life of the installation.
6 • Redox opinion (by Timothy L. Miller on 2024-10-07 04:16:51 GMT from United States)
IMO, still FAR too early to bother. Downloaded the demo and desktop images to try in QEMU/KVM with virt-manager as a frontend. Neither even booted to test. Worthless garbage at this point unless you're a developer wanting to work on the project.
7 • Static linking... (by Vip2 on 2024-10-07 04:22:44 GMT from United States)
@2 "Sure, we don't have as many limits in terms of disk or memory anymore, but a lot of people still have limits on their bandwidth and/or the time they are willing to spend updating their operating system."
Bandwidth is also not really an issue if Delta updates are used to update the static packages. No need to download the whole package, only the changes. Whether or not that is fully implemented is something I am not sure of. I did find some posts about flatpacks supporting delta updates in Fedora from 2020
8 • Redox (by Andy Prough on 2024-10-07 05:15:31 GMT from Switzerland)
I tried Redox, and it seems pleasant but you can't really do anything useful with it, it's just a demo.
I don't really see the point of reviewing a demo that has no ability to do any productive work or run any useful programs. Seems better to wait to see if it ever becomes anything or if it just dies out like so many of these projects.
9 • Unified package managers/universal package formats (by grraf on 2024-10-07 07:11:59 GMT from Romania)
It all sounds so nice in theory but in practice all we get is a lot of extra bloating(since everything and its mother comes with its required dependencies to run regardless of distro in the case of universal packages) and a lot of potential mishaps and conflicts can occur when a UPM starts calling&giving each successive package manager free reign to alter the OS... its no coincidence most sane distros advise sticking to&using just one package manager. As far as i'm concerned both practices are to be avoided , not encouraged but its no skin of my back if folks care to play russian roulette with the integrity of theyr OS... ill be blunt and say it: if you need an up to date distro then switch to a rolling one and if you want access to a larger repo of apps then switch to a distro that has just that...
Stop trying to turn your honda civic into a ferrari by slapping in random parts into it that weren't designed to fit in there in the first place just so you could avoid moving away from the ever so familiar&comfortable honda civics controls&design... you are just stalling the inevitable while asking for trouble in return for your misguided 'efforts'
10 • RedoxOS (by uz64 on 2024-10-07 07:48:24 GMT from United States)
I tried Redox OS and it is too early to give a real opinion on it because it has so far not come even close to the standards I would expect for a "usable" operating system--either in a virtual machine or on real hardware (though through Ventoy). It is clear very new, still heavy in development, still clearly nowhere near production ready, and my testing of it only confirms that. I have run into problems with booting, primarily in VMs, and on real hardware I had driver problems (specifically: not even the USB mouse I had hooked up to my laptop would work, I was restricted to the built in keyboard and trackpad). I don't remember if Wi-Fi worked or not, but by that point it doesn't even matter.
Honestly, I am far more interested in Serenity OS, but it currently runs in a KVM setup, with no way to install on real hardware yet. But it still feels more polished and I love its retro 90s style design on a UNIX-like base. Still, Redox is making some big strides and I hope to see them both become usable and installable on real hardware in the future. But for now... they're both nowhere near the point of even considering for real use on any system other than testing and as a hobby.
11 • Redox (by Kazlu on 2024-10-07 08:42:49 GMT from France)
The concepts are really interesting, and the fact that several devs have joined confirms that there is potential here. Of course, hardware compatibility will be a problem for a long time, considering it is still regularly a problem even for Linux... But I think Redox may not be so far from being usable in some niche cases. If one can run Redox in a container within GNU/Linux or a BSD and Redox supports a portable package format like Nix, this can be a real bonus for security by isolation. I think this may peak the interest of projects like Qubes OS in particular.
I voted that I have no plan to try it (yet), because I do not have the time to dig in a project in such an early stage of developpement. But I will definitely keep an eye on it.
12 • Works on VM, but on Hardware is a bit frustrating (by Will on 2024-10-07 09:09:29 GMT from United States)
It's pretty experimental in my view. I have a lot of commodity and modern hardware lying around and although I got it working, it required a bit of this and a bit of that to get a workable system. I got really frustrated with keyboard, trackpad and wifi.
Maybe if the devs would target something like a reasonably recent laptop configuration it'd get more interesting.
Once it's up and running, it doesn't take long to figure out "what it does" and what it does is run apps and such. The interface is fine, but I got bored pretty quick. I'm looking forward to a future release that isn't quite so much work to get working that supports a more standard configuration of hardware - I don't mind cobbling stuff together, but I really want the built in keyboard to work on my laptop :).
13 • Static linking (by Tom on 2024-10-07 09:53:15 GMT from Belgium)
@7 "Bandwidth is also not really an issue if Delta updates are used to update the static packages. No need to download the whole package, only the changes. Whether or not that is fully implemented is something I am not sure of. I did find some posts about flatpacks supporting delta updates in Fedora from 2020"
Even if binaries depending on an updated library could be efficiently patched, it would require more energy to do so, and it would still be necessary to update *all* the binaries relying on that library. The other problem is the inter-dependencies of the libraries themselves, which would make any update trigger a ripple effect through all the libraries, and through all the binaries depending on them, possibly several times.
It's a huge waste of bandwidth, disk space, memory, and energy. And that's on top of the security issues mentioned earlier, and possibly the missed opportunity of optimized libraries for a specific architecture.
The concept is as flawed as the one of universal packages, if not more.
14 • These really don't want Linux to get more popular. (by Aetherlina on 2024-10-07 09:54:56 GMT from Czechia)
"Unified package manager is a recipe for disaster, used by lazy developers/maintainers to avoid having to repackage/support their native package format, update software and to address code review and security issues properly."
Says for itself.
15 • Universal (by Jesse on 2024-10-07 10:25:45 GMT from Canada)
@4: "So what does a unified package management do exactly behind the scene? The description sounds like nothing more than a wrapper/alias for various (traditional) package managers"
Yes, this is accurate.
"I used to consider it as a universal converter which would translate different types of package"
No, not at all. That would be a converter or package translator, like Alien. It is a completely different class of utility.
16 • Universal package managers (UPM) (by DachshundMan on 2024-10-07 10:46:47 GMT from United Kingdom)
I try not to use universal packages as I consider them to be software bloat and I do not need that on an old computer like mine (7th gen i5). However, there are a few programs that are not available in deb format and which I need so I do use a few. In that case they need to be kept secure and I like the idea of the updating being done by one UPM.
I think that those who mention "lazy developers" are doing a big disservice to the many developers who spend a lot of time packaging programs. It is likely that 80% of the users will use 20% of the distros so if your development time is limited then it makes sense package for only the widely used distributions and then make a universal package for the rest.
What would be good is to somehow be able to verify that the universal packages are "safe" which is part of what the packagers at, for example, Mint do
17 • redoxOS (by rhtoras on 2024-10-07 10:52:55 GMT from Greece)
The good thing with redox os is it does not contain systemD. The bad thing is it relies fully on rust language. I won't dive deeper into this but rust i a controversial topic. It relies fully is the problem not rust itself. It is not usable yet. What is to be considered is pkg. PKG already exists and i am not sure if it is the same package manager modified to run on redox. Using the exact same name (as on freebsd or open indiana) might be a problem. If we talk for the same pkg package manager then it's fine. A good package manager imho with a lot software if someone uses pkg_src ports etc fro bsd/illumos unix. Thanks for the review Jesse...
18 • Linux freezing, IP6 problem, solution? (by Jan on 2024-10-07 11:17:09 GMT from The Netherlands)
I encountered Linux freezing at different distro-testing rather often.
Possibly the reason and a solution: https://www.dedoimedo.com/computers/linux-kernel-network-ipv6-problem.html
19 • Redox opinion p. (by Europe on 2024-10-07 13:24:11 GMT from Germany)
I have downl. Redox the live ISO (1.6 GB) Started it with Gnome Boxes. The boot script did its Calculation to the middle of the Screen. Then it, was hanging on one spot for like 15 Min. Never finied.. It's boot calculation. Doing something for ever. I forced shutdown option.. GBoxes off. Deleted the ISO. The End. Thank You.
20 • Appimage, snap, flatpak (by Orlando on 2024-10-07 13:48:01 GMT from Italy)
@14 I would say: "Appimage, Snap and Flatpak are a recipe for disaster, used by lazy developers/maintainers to avoid having to repackage/support their native package format, update software and to address code review and security issues properly."
I hope more Linux distributions come out that don't use this garbage.
21 • Redox (by Robert on 2024-10-07 16:50:56 GMT from United States)
I am interested in trying Redox - eventually. They have good ideas and I'm interested in how far they can take them. Hopefully they end up with a real competitor. But for now, regardless of any other issues I don't see an OS that doesn't even support USB as even worth trying.
The desktop is their own custom thing called Orbital. Used to also have its own utility applications before porting the COSMIC ones. I believe the eventual plan is to bring over COSMIC in its entirety and drop their bespoke solution.
22 • Some other advantages of universal packages (by vw72 on 2024-10-07 18:22:40 GMT from United States)
I tend to run Gnome as my desktop, but there are a few KDE apps that I regularly use, such as Blender. Running Blender from a flatpak keeps the rest of my system "clean" from having all of the kde and qt dependencies being installed throughout my system. The downside is that it can take up more disk space, but that is usually not a problem for me.
I also am interested in the immutable OSs that Fedora and openSUSE are working on. In these systems, the core system is unchangeable (until the user specifically updates it) and most apps are run as flatpaks. While not everyone will have a use case requiring an immutable system, if you do, then these two projects are definitely exciting.
Another advantage to at least flatpaks and appimage (and possibly snaps, although I don't use them, so I don't know), is that if the computer is shared among family members or coworks, these applications can be installed in the user's home directory versus universally being available. While there are ways to restrict rpm and deb applications to specific users, installing a flatpak or appimage to a home directory is a lot quicker and simpler.
Finally, flatpaks and appimages often have more recent versions of software than what is in a distro's repo. Run a long term release and want the latest libreOffice, flathub will have it. Have a 3d printer and want the latest Cura? Ubuntu is still on version 4.13 while flathub has the latest.
Are flatpaks and these others perfect? No, they can always be improved. But they sure can be convenient depending on your use case.
23 • Unified package management vs universal package formats (by Vukota on 2024-10-07 22:02:13 GMT from Serbia)
To quote myself
"Unified package manager is a recipe for disaster, used by lazy developers/maintainers to avoid having to repackage/support their native package format, update software and to address code review and security issues properly."
Which part of this was incorrect? Recipe for disaster is that unified "package manager" (doesn't matter what kind of package format it combines) is combining parts that are not meant to work together. It allows you this, so that you don't need to "buy" part (package) meant to work with rest of your system in intended/designed/tested/secured way, and thus is cheaper ("lazy maintainers" = cheap way to not get proper "part") to put together whole distribution and then claim that they have everything that you need.
Now, if you meant that it will make your life easier and your system up-to-date across these different origins, that may be true to a degree, but it is still negative that it is masking all underlying problems with it by making you think you are safe and good.
"I know Flatpaks/Snaps/AppImages have their own "good" sides, but it still comes down to my first conclusion."
Which part of this was incorrect? Usually, though not always, unified "package manager" will mix some more or less "native" packages (in different formats) with packages in Flatpaks/Snaps/AppImages format and reasoning here is exactly the same why "Unified package manager" exists in the first place (so that maintainers don't have to repackage all dependencies in their native format that has shared components with other packages and that they don't have to review the code at all). Only different approach here with in example Flatpacks is that there is a sand-boxing that is supposed to protect you "on paper" (but not reality) from some types of malicious attacks. So in short, nothing here is mixed up.
24 • Universal package manager (by Vinfall on 2024-10-08 01:38:34 GMT from Hong Kong)
@15: Thanks for the clarification, Jesse. After checking the source code of rhino-pkg, I think for now it's still a dream sounds too good to be true :( Pacscript (Pacstall package template) is also a bit complicated due to its blending nature.
By the way, I recall using alien back in the days when I use Debian stable and backport cannot satisfy my need. Forgot the name for a long time and good to know that!
25 • Redox OS (by rednex on 2024-10-09 00:23:25 GMT from United Kingdom)
Most alternative OSs have restrictions and eccentricities.
Redox OS has no restrictions. It is aimed at being a replacement for Linux / BSD: It can port Linux apps. it is led by a software engineer who already works on a Linux OS.
So as long as they don't get too obsessed with Rust, they should be able to overtake other alternative OSs and become a new desktop force.
26 • Redox (by penguinx86 on 2024-10-09 14:09:15 GMT from United States)
Redox sounds like a work in progress. Not ready for prime time. I'll stick with more mainstream distros like Mint, Debian or Fedora that will be around for a while and are reasonably well supported.
27 • Redox OS, BSD (by Otis on 2024-10-09 16:20:04 GMT from United States)
Both Redox OS and BSD have something important in common: They've been around long enough to be fully developed, and successful. Of course, many fully developed Linux distros have come and gone, so perhaps we should leave out successful in our remarks about these projects, even though there are dozens of very successful Linux distros.
Redox OS was begun in 2015, and BSD in 1978. So 46 years of BSD development and testing and bug reports etc has still not produced an OS that very many users want, need, can rely upon, etc. And 19 years of the same from Redox OS.
I'm sure there is a long list of real good reasons for each of those projects to be where they are, perhaps a short list of reasons, I don't know.
Are we stating the obvious or misrepresenting to observe that what Linus Torvalds uncorked was the needed response to Microsoft (and Apple)? And not BSD? And likely not this Redox OS (well intentioned) micro-kernel project?
28 • Lots of 2c-worth ends up being far less than the sum of its paths (by Jeff on 2024-10-09 20:17:17 GMT from Australia)
It's staggering to me that Jesse can put forward such a well nuanced piece, so succinctly, about explaining package management, then other (ab)users chime in with almost silly oneliners that _sound_ devoid of thought and riddled with prejudice.
Jesse, I am one of your many admirers who are constantly amazed by your patience, courtesy, knowledge and expressiveness. Long may your words and example live.....
29 • redox (by rednex on 2024-10-09 23:04:22 GMT from United Kingdom)
@27 "Redox OS was begun in 2015, and BSD in 1978. So 46 years of BSD development and 19 years of the same from Redox OS."
That's 9 years for Redox - not 19 - on a part-time basis. That's not bad when you're using an evolving (Rust) language.
BSD has always been focused on correctness of code. FreeBSD is only now wanting to include more hardware driver support. ReactOS and Haiku are around 20+ years old. They are restricted by compliance to legacy systems. Minix was aimed at an educational audience. Menuet and Collobri OSs are small, assembly language efforts. Serenity OS is for developers, not users. Sky and Syllable OSs got closest to being usable desktops, but they had developer problems.
In OS development it's the attitude that counts. And Redox devs seem to have the right attitude of aiming at being a desktop challenger without restrictions. So it should be able to progress further than other efforts.
30 • redox, @29 (by Wally on 2024-10-10 02:37:10 GMT from Australia)
"In OS development it's the attitude that counts." I beg to differ. What counts is the competence of the developers and the quality and usefulness of the product.
"a desktop challenger without restrictions. So it should be able to progress further than other efforts." Perhaps, but I won't hold my breath. BSD is successful, competent and useful in it's niche. If it's held back, it's not because of concentration on 'correctness of code'. In a FOSS forum, it's the proverbial elephant in the room: money. Developers need to eat and have families to feed. If BSD gets a few hundred thousand dollars from some deep pocketed entity, they're ecstatic. Meanwhile, Linus Torvalds alone gets a 1.5 million salary, give or take. That's not to mention the contributions by IBM/Red Hat, Microsoft (Yes, Microsoft!) and a bunch of other really deep pockets via employing developers and The Linux Foundation.
But even with all that support, in the desktop universe, Linux is still somewhat of a niche product. Not that I mind. I enjoy Linux and wish redox well, but I'm currently in Australia, not fantasyland.
31 • Niche/successful projects (by Kazlu on 2024-10-10 10:11:09 GMT from France)
"But even with all that support, in the desktop universe, Linux is still somewhat of a niche product."
Absolutely not. Linux is used in many more machines than Windows now. The catch is that is is way less visible, because the very large majority of those machines are not desktop computers... Linux is indeed a niche product in the desktop computer market, but that's it. And big investors like Micrsoft and especially Google invest more towards the server/embedded scope for Linux than for the desktop scope. And then, if you factor in Android (which uses the Linux kernel but is not a GNU/Linux distribution), that goes even wider and you are really close from a "desktop".
BSD also has, to my knowledge, a wider niche in the server department than in the desktop department.
Anyway, your point still stands: money is indeed a big driver for OS development. But it's not surprising that the big investments in Linux are not all geared towards desktop features and wider Linux desktop adoption.
32 • Niche/successful products, @31 (by Wally on 2024-10-10 10:43:22 GMT from Australia)
@31, Huh? Me: "in the desktop universe, Linux is still somewhat of a niche product." You: "Absolutely not. . . . Linux is indeed a niche product in the desktop computer market,"
Are you agreeing? Disagreeing? Contradicting yourself?
33 • @32 Niche/successful products (by Kazlu on 2024-10-10 12:34:35 GMT from France)
Wow, really sorry about that, I completely overlooked that you *did* mention "desktop" in your last comment... I messed up, simple as that.
I can still say that a lot of the Linux support goes more towards servers and embedded systems than desktop, but certainly not in the way I put it. Sorry again.
34 • Oops, hello... (by Otis on 2024-10-10 15:46:40 GMT from United States)
@29Nine years, not 19 as I stated.
But that still for one new project like that seems long. Nit-picking I guess. My main qualm with Redox OS is that it seems futile as we've seen robust kernel and overall distro(s) development in the Linux world. Have fun with microkernel, okay.
That you report about BSD comes from a learned mind about such things (to me anyway). But again, it seems like that effort and the overall project itself is more a labor of love for the old days or whatever than a genuine realistic endeavor to cause BSD to be a neck-and-neck alternative to Linux for the masses.
I have noticed that the shortcomings of GhostBSD, for example, are FreeBSD's shortcomings largely. And that causes us to notice that Linux has not those shortcomings, as a kernel and driver support, etc. Yes, one can encounter those shortcomings if one is inclined to distro hop; there are distros out there that make some new users scurry back to Windows or Mac. But we all know that good, popular, polished Linux distros are what Linux is about now days, and that one can never have to look back once "your" disto is on that machine you work and/or play on.
35 • unified PM and universal package formats (by JR on 2024-10-11 01:39:06 GMT from Brazil)
Well, first of all, I appreciate Unix principles, especially the clear separation between libraries and the executable software. However, I have some opinions about unified package managers and universal package formats.
It seems to me that unified package managers will exacerbate the dependency hell, beyond any other potential issue. It's like installing Arch packages with pacman, Debian packages with apt, SUSE packages with zipper, Fedora packages with dnf, Flatpak packages with flatpak, and Snap packages with snap, all within the same distribution.
Even with a single package format and manager, you can still encounter unresolved dependencies. So, what do you think about using various package managers with various package formats? A unified package manager is essentially a frontend to all supported package managers.
Therefore, there's a high chance of ending up with a broken distribution without a solution. This is not for me.
But I think universal package formats have potential. They could become the application format for distributions, separate from the operating system itself. This would allow for independent updates, similar to BSD. I don't see this as a problem.
For example, elementary OS uses this approach. It can be very stable if you avoid mixing multiple package formats. You can use one format for the OS (the traditional way) and another format for applications.
In elementary OS, you have apt updating the system and flatpak updating applications. This can work very well and may become the standard for many distributions.
It simplifies the distribution maintenance.
What do you all think?
36 • Unified package management (by Jesse on 2024-10-11 12:37:18 GMT from Canada)
@35: " So, what do you think about using various package managers with various package formats? A unified package manager is essentially a frontend to all supported package managers.
Therefore, there's a high chance of ending up with a broken distribution without a solution. This is not for me."
Yes, unified package managers are front-ends for other package managers/formats. No, there is not an increase in chance of dependency issues. How could there be? When you install a package from, for example, a Deb archive, it's pulling in the software and its dependencies from the Deb archive. When you install a Flatpak it has all of its dependencies built in. When you install something from Pacstall, it pulls its dependencies from Pacstall.
A unified package manager isn't going to pull in an application from one repository and a dependency from another repository, because that's not how the underlying package managers work. The unified package manager is just a front-end to what the underlying package managers do, it doesn't mix and match packages from the underlying repositories.
37 • @36 (by JR on 2024-10-11 23:13:10 GMT from Brazil)
First of all, thank you for responding, I'm honored to talk to a person with so much knowledge and expertise.
So, I think my English is really bad, because that's not what I intended to say at all.
Let's see if I can explain myself.
II'm imagining that if you use a single package manager with a single type of packages, you may have unresolved dependencies (traditional distributions).
and when you mix other package managers with other types of packages in the same distribution (even though each one pulls the packages from their own sources), the chances of unresolved dependencies increase, not because they mix, but for numerical reasons, you may have for example apt with unresolved dependencies (although it is rare) and another package manager with unresolved dependencies.
not because they got mixed up, but because instead of one, there are two, just for that reason, it increases the chances of an error happening, simply by having two package managers, and not just one, it's a matter of statistics. Obviously the two will not mix, these are things that will happen concidentally, occasionally.
If you only use one PM, you have a chance of having problems with dependencies, if you use two, the chances increase, because there are two, not one.
Furthermore, what do you think would happen if you could use each one independently, and install the same software, on the same system, with two different PMs, each with its own source?
I really don't know if it would be possible, just guessing that if several package managers are installed, why couldn't we use each one separately?
38 • Unified package managers (by Jesse on 2024-10-11 23:27:40 GMT from Canada)
@37: I see what you are saying, about using more package managers could, in theory, result in more problems. And that makes a certain amount of sense. If one piece of software has N number of issues than three separate pieces of software might be expected to have 3xN issues.
However, it should be very very rare, if it ever happens, that you run into dependency issues with official repositories or portable packages. I'm not saying it's impossible, but it's highly unlikely, especially in stable/static distributions. For a package to make it into Debian Stable, Ubuntu, or RHEL (as a few examples) it needs to go through a lot of testing and should not make it through to user-facing repositories if it has any dependency issues.
In theory a dependency might sneak through all the QA, maybe on a rapid-fire rolling release distribution, but practically it's unlikely.
For that matter, portable packages like Snap and Flatpak don't have external dependencies (apart from systemd for Snaps) so they can't increase the number of possible dependency issues.
"Furthermore, what do you think would happen if you could use each one independently, and install the same software, on the same system, with two different PMs, each with its own source?"
You end up with two entries in the application menu. Portable packages install in different locations from classic packages so there is no conflict. Third-party repositories (AUR and Pacstall) usually don't allow conflicts with the parent distro, or require a different install name/location, so there is no conflict between files/versions.
39 • @38 (by JR on 2024-10-12 00:07:43 GMT from Brazil)
"You end up with two entries in the application menu. Portable packages install in different locations from classic packages so there is no conflict. Third-party repositories (AUR and Pacstall) usually don't allow conflicts with the parent distro, or require a different install name/location, so there is no conflict between files/versions."
I mean in relation to the simultaneous use of traditional PMs, for example, apt will install Firefox in certain directories, right? What if we install it on the same system, the same Firefox, but with Pacman for example?
I understand you when you say that there would be no problems mixing the traditional method with snaps or flatpaks, as these have their own location with all the files embedded, but two traditional PMs would theoretically install in the same directories....
Then you uninstall with one PM, and the other still computes as installed, and theoretically it would also try to update a package that was removed...
It seems like a huge mess to me
it would be necessary not to allow the independent use of PMs, as the frontend would have to deal with these situations, not allowing it to happen, I think
40 • Unified package managers (by Jesse on 2024-10-12 03:27:40 GMT from Canada)
@39: "I mean in relation to the simultaneous use of traditional PMs, for example, apt will install Firefox in certain directories, right? What if we install it on the same system, the same Firefox, but with Pacman for example?"
You don't. Or can't. Even with unified package managers, you don't run two classic package managers on the same system. The packages which you'd get from a Pacman repository (for Arch, for example) would be no good to someone running a Debian-based system with APT. There aren't any situations where unified package managers use multiple classic package managers.
This is why there is no risk, the unified package manager isn't just accessing packages from different sources, it is also dealing with different _types_ of packages. This generally goes in layers. For instance, Deb pacakges, Snap, and Pacstall. Or RPM, Flatpak, and Nix. You never see unified package managers try to mix Deb, RPM, and Pacman.
"I mean in relation to the simultaneous use of traditional PMs, for example, apt will install Firefox in certain directories, right? What if we install it on the same system, the same Firefox, but with Pacman for example?"
This is one of those situations that can't happen because it would require mixing two traditional package managers, which doesn't happen. The worse or most confusing case you'd run into would be installing Firefox through Deb and then again through Flatpak, which use different locations.
"Then you uninstall with one PM, and the other still computes as installed, and theoretically it would also try to update a package that was removed..."
This doesn't/can't happen as well because different package managers don't share the same package database.
Number of Comments: 40
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 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 |
• Issue 1073 (2024-06-03): LXQt 2.0.0, an overview of Linux desktop environments, Canonical partners with Milk-V, openSUSE introduces new features in Aeon Desktop, Fedora mirrors see rise in traffic, Wayland adds OpenBSD support |
• Issue 1072 (2024-05-27): Manjaro 24.0, comparing init software, OpenBSD ports Plasma 6, Arch community debates mirror requirements, ThinOS to upgrade its FreeBSD core |
• Issue 1071 (2024-05-20): Archcraft 2024.04.06, common command line mistakes, ReactOS imports WINE improvements, Haiku makes adjusting themes easier, NetBSD takes a stand against code generated by chatbots |
• Issue 1070 (2024-05-13): Damn Small Linux 2024, hiding kernel messages during boot, Red Hat offers AI edition, new web browser for UBports, Fedora Asahi Remix 40 released, Qubes extends support for version 4.1 |
• Issue 1069 (2024-05-06): Ubuntu 24.04, installing packages in alternative locations, systemd creates sudo alternative, Mint encourages XApps collaboration, FreeBSD publishes quarterly update |
• Issue 1068 (2024-04-29): Fedora 40, transforming one distro into another, Debian elects new Project Leader, Red Hat extends support cycle, Emmabuntus adds accessibility features, Canonical's new security features |
• Issue 1067 (2024-04-22): LocalSend for transferring files, detecting supported CPU architecure levels, new visual design for APT, Fedora and openSUSE working on reproducible builds, LXQt released, AlmaLinux re-adds hardware support |
• Issue 1066 (2024-04-15): Fun projects to do with the Raspberry Pi and PinePhone, installing new software on fixed-release distributions, improving GNOME Terminal performance, Mint testing new repository mirrors, Gentoo becomes a Software In the Public Interest project |
• Issue 1065 (2024-04-08): Dr.Parted Live 24.03, answering questions about the xz exploit, Linux Mint to ship HWE kernel, AlmaLinux patches flaw ahead of upstream Red Hat, Calculate changes release model |
• Issue 1064 (2024-04-01): NixOS 23.11, the status of Hurd, liblzma compromised upstream, FreeBSD Foundation focuses on improving wireless networking, Ubuntu Pro offers 12 years of support |
• Issue 1063 (2024-03-25): Redcore Linux 2401, how slowly can a rolling release update, Debian starts new Project Leader election, Red Hat creating new NVIDIA driver, Snap store hit with more malware |
• Issue 1062 (2024-03-18): KDE neon 20240304, changing file permissions, Canonical turns 20, Pop!_OS creates new software centre, openSUSE packages Plasma 6 |
• Issue 1061 (2024-03-11): Using a PinePhone as a workstation, restarting background services on a schedule, NixBSD ports Nix to FreeBSD, Fedora packaging COSMIC, postmarketOS to adopt systemd, Linux Mint replacing HexChat |
• Issue 1060 (2024-03-04): AV Linux MX-23.1, bootstrapping a network connection, key OpenBSD features, Qubes certifies new hardware, LXQt and Plasma migrate to Qt 6 |
• Issue 1059 (2024-02-26): Warp Terminal, navigating manual pages, malware found in the Snap store, Red Hat considering CPU requirement update, UBports organizes ongoing work |
• Issue 1058 (2024-02-19): Drauger OS 7.6, how much disk space to allocate, System76 prepares to launch COSMIC desktop, UBports changes its version scheme, TrueNAS to offer faster deduplication |
• Issue 1057 (2024-02-12): Adelie Linux 1.0 Beta, rolling release vs fixed for a smoother experience, Debian working on 2038 bug, elementary OS to split applications from base system updates, Fedora announces Atomic Desktops |
• Issue 1056 (2024-02-05): wattOS R13, the various write speeds of ISO writing tools, DSL returns, Mint faces Wayland challenges, HardenedBSD blocks foreign USB devices, Gentoo publishes new repository, Linux distros patch glibc flaw |
• 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 | 
OpenELEC
OpenELEC was a Linux-based embedded operating system built specifically to run Kodi, the open source entertainment media hub. The idea behind OpenELEC was to allow people to use their Home Theatre PC (HTPC) like any other device one might have attached to a TV, like a DVD player or Sky box. Instead of having to manage a full operating system, configure it and install the packages required to turn it into a hybrid media center, OpenELEC was designed to be simple to install, manage and use, making it more like running a set-top box than a full-blown computer.
Status: Discontinued
|
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.
|
|