 DistroWatch Weekly |
| DistroWatch Weekly, Issue 1079, 15 July 2024 |
|
Welcome to this year's 29th issue of DistroWatch Weekly!
The developers of Linux distributions are regularly looking for ways to provide more or better experiences while also reducing their maintenance burden. These efforts often result in old components being replaced by new ones that are easier to maintain or which are developed elsewhere. In our News section we talk about a number of these efforts to reduce the burden of maintenance, such as Fedora phasing out X11 packages from the project's Workstation edition. We also talk about Red Hat making plans to replace the GRUB boot loader as the FreeBSD team shortens their project's release cycle. We also report on UBports getting a new first-run wizard as another OpenSSH vulnerability is revealed which has shown up in the Red Hat family of distributions. Before we cover these news stories we take a look at Ubuntu Core, an immutable distribution which seeks to streamline and automate system maintenance. Jesse Smith shares details in his look at Ubuntu Core 24 in our Feature Story. Do you use an immutable distribution, such as openSUSE's Leap Micro, Fedora's Silverblue, or Ubuntu Core? Let us know which is your favourite in this week's Opinion Poll. This week we also share some thoughts on trying to hide files on Linux systems and talk about last week's releases. Plus we are pleased to list the torrents we are seeding. We wish you all a terrific week and happy reading!
This week's DistroWatch Weekly is presented by TUXEDO Computers.
Content:
|
| Feature Story (By Jesse Smith) |
Ubuntu Core 24
Commercially backed Linux vendors, such as Fedora and openSUSE, have been promoting their immutable or atomic editions for a while now, and it looks as though commercial interests are planning to gradually place more focus on the immutable flavours of their distributions.
Immutable platforms certainly have an appeal, especially for vendors who may need to provide support. An immutable base is typically minimal, fixed (read-only), and upgraded atomically. All of these characteristics streamline testing and support while, ideally, making upgrades more reliable.
While I have tried out openSUSE's immutable edition and Robert Rijkhoff has test driven Fedora's atomic Silverblue distribution for DistroWatch, I had not yet tried Canonical's Ubuntu Core immutable branch. This week I decided to try out Ubuntu Core 24 and see how it compared to the equivalent offerings from Fedora and openSUSE.
What is Ubuntu Core? The Ubuntu documentation describes the Core edition as follows:
Ubuntu Core is a version of the Ubuntu operating system designed and engineered for deploying IoT and embedded systems.
In Ubuntu Core, every element of the system runs within a confined sandbox using Snap packages, which [are] used exclusively to create a transaction-based system. Security and robustness are the key features, alongside being easy to install, easy to maintain, and easy to upgrade.
Ubuntu Core is ideal for embedded devices because it manages itself. Whether it's running on a PC-style system hidden for media streaming, or an embedded ARM device handling garage door automation, Ubuntu Core remains transparent, trustworthy and autonomous.
Ubuntu Core runs on some ARM devices, such as Raspberry Pi computers, and x86_64 computers. The generic images of Core are available as compressed IMG files which are about 450MB in size. Once these files are uncompressed, they expand to around 3.7GB.
The Core edition of Ubuntu does not feature a system installer. We write the IMG file directly to an SD card or hard drive and then the first time Core boots it sets up and expands its partitions to fill the entire disk. This means, at least when using a generic laptop or desktop computer, we need to use another distribution (typically a live desktop distribution) to download and write the IMG to the local disk. I downloaded the generic x86_64 build of Core and wrote it to my hard drive using a copy of Linux Mint.
Installing
The first thing I discovered about Ubuntu Core was it required UEFI support to boot, the distribution was incapable of booting in Legacy BIOS mode. The first time the distribution boots it appears to setup the disk and then restart. The system then displayed a text console and prompted me to press Enter to begin the initial configuration process.
There are really just two configuration steps. The first text-based configuration screen gives us the chance to configure our network interfaces, assigning IPv4 and IPv6 addresses. We can also use DHCP to assign addresses to available interfaces. This screen kept filling up with systemd status messages while I was trying to navigate it, mangling the input fields and necessitating multiple trips back and then forward again through the steps to clear the display. The following screen asks us for our Ubuntu single sign-on (SSO) e-mail address. The configuration process will not proceed without a valid SSO account e-mail address.
The first time through the setup process, Core was unable to detect my network card; it was not displayed on the network configuration page. I was allowed to proceed to the single sign-on page, but without a working network connection it was impossible to verify my account. This left me in a position where I couldn't back out of the setup program and could not proceed.
I'd like to take a moment to explain an aspect of Ubuntu Core. Unlike Fedora and openSUSE which can create and manage multiple local user accounts, Ubuntu Core relies entirely on a single user account (so far as I can tell it is not possible to create additional accounts) and this account must match an Ubuntu SSO account. The name of the user account on the system will match the e-mail address used to sign into Ubuntu SSO. In place of passwords, Core downloads our public OpenSSH key from our SSO account. We then sign into our copy of the Core system remotely using OpenSSH. There does not appear to be any local account sign option or a way to forego using OpenSSH keys in favour of passwords. There also does not appear to be any way to set up local accounts instead of ones registered with the Ubuntu SSO service.
I eventually tried forcing a reboot of my machine and, the second time through, my network card was detected. I was able to set up IPv4 and IPv6 addresses. When I proceeded to the SSO page I put in my e-mail address and Core reported an error "Cannot create user (myaccount): no ssh keys found". I realised no keys were registered with my SSO account. I had to then create a key on another computer, sign into the Ubuntu SSO website, and upload my new key. Then Core's setup program automatically downloaded my public key. We do not need to provide a password for our SSO account which feels weird to me, though since only our public OpenSSH key is downloaded, it's probably not an issue. The worst an attacker is likely to be able to do is accidentally grant us access to their own systems.
I want to underline the point that I'm not thrilled with requiring an on-line account to set up a Linux distribution. I'm especially not happy with the requirement of providing our credentials to a third-party website in order to sign in to a machine on our local network. This feels overly engineered and less secure than using passwords off-line or security keys locally.
First impressions
The next time Ubuntu Core boots it brings up a text console. Instructions for signing in remotely are displayed on the screen. For example, my Core machine was running on IPv4 address 192.168.2.32 so a line reading "ssh jesses@192.168.2.32" was shown. I found there are other local terminals we can view, each with a login prompt. However, since we cannot use a password to sign in, these login prompts are useless.
When we sign into our Core account remotely, a welcome message in the terminal provides us with links to documentation and suggests we can use Snap to set up packages. A web kiosk is suggested, though other project ideas, such as a Nextcloud service, are mentioned in the documentation.
Shortly after signing in for the first time, a console broadcast message was displayed. This message warns the system will automatically reboot at a time in the future, about three hours into the future, in my case. I didn't want this to happen and was looking about for a way to cancel the reboot, or at least find out why a reboot was required, when (about 60 seconds later) the system restarted. It was at this point I realized Core's clock was set to the wrong timezone.
Setting the clock works differently on Core since the distribution is immutable; we cannot use the usual tools, such as date and related utilities, to set the clock or the timezone. Instead the Core documentation instructs users to run the Snap command to set a system-wide variable which will fix the timezone. Specifically, the command is:
snap set system system.timezone="America/Chicago"
We can see all system variables by using another Snap command:
snap get -d system
This second command allowed me to see which variables were present and then set my hostname by running the following command:
snap set system system.hostname="fred"
Exploring the system
As I mentioned before, Core is an immutable distribution and features a read-only filesystem. We can then layer data files on top (in our home directory) and install Snap packages for additional functionality. As far as I could tell, there wasn't any way to set up additional user accounts. Tools like useradd are installed, but do not work because of the read-only filesystem. Similarly, there didn't appear to be any option for adding a desktop environment. Core seems to be focused exclusively on being a minimal server system. With this said, there are kiosk options for Core. For example, we can set up a kiosk system running just Firefox or the Kodi media player.
How minimal is Core? The distribution uses about 1GB of disk space and, without any services apart from OpenSSH running, 260MB of RAM is consumed. No swap space is enabled during the install process.
Adding services through Snap
We can add services to Core using Snap packages. Snap can help us find available packages by running "snap find" and install new items using "snap install". As I had already experienced, Snap will automatically update packages for us and reboot, whether we want the updates or not. All Snap commands can be run without being the root user or prefixing the Snap command with sudo. All commands are effectively run as the administrator.
At this point I had a minimal system, but couldn't really do much with it. There were very few services and no graphical environment. There aren't even any local manual pages. I decided to find something to do and tried to set up two services: a torrent seedbox and a Nextcloud private cloud service.
Something I noticed when I went looking for Snap bundles is that the Snap command assumes our terminal is quite wide, over 100 characters wide. In terminal windows less than about 120 characters the text from the "snap find" command wraps, distorting the lines and making it hard to read the results of our searches.
Despite the poorly formatted output from Snap, I was able to find some torrent packages, one of them bearing the name transmission-daemon-simosx. I installed this package and then went looking for the Transmission configuration file, which I found under my user's /snap directory. Specifically, the file is located at: /snap/transmission-daemon-simosx/current/.config/transmission-daemon/settings.json. After adjusting a few settings, such as granting access to my remote computer to control the torrent daemon, I was then able to launch the service using the command transmission-daemon.
Ubuntu Core 24 -- Remotely accessing the Transmission daemon
(full image size: 38kB, resolution: 1182x824 pixels)
At this point I was able to check on the status of my torrent seedbox by running the transmission-remote command from my laptop. For example, the follow command would list active torrents: "transmission-remote 192.168.2.32 --list". The command "transmission-remote 192.168.2.32 --add https://tails.net/torrents/files/tails-amd64-6.4.img.torrent" would add the Tails distribution torrent to my seedbox. This first experiment was a pretty easy success.
Setting up Nextcloud to provide private file synchronization and cloud services was even easier. I ran the command "snap install nextcloud" and then pointed my laptop's web browser to my machine running Core on network port 80. The Nextcloud service responded, walked me through setting up login credentials for Nextcloud, it offered to install popular services automatically, and then signed me into my new Nextcloud environment. It was all quite automatic, smooth, and problem-free.
Ubuntu Core 24 -- Running the Nextcloud service
(full image size: 211kB, resolution: 1488x839 pixels)
Thoughts and conclusions
When I first started looking at Canonical's immutable branch of Ubuntu, I was expecting to find something like Fedora Silverblue or openSUSE's MicroOS/Micro Leap/Aeon. Fedora's and openSUSE's atomic flavours are pretty close to the more mainstream, writable versions of their respective distributions. In other words, if you're running openSUSE's MicroOS, it's pretty close to the experience you'd get running openSUSE's more commonly used Leap edition. Running Fedora Silverblue looks and feels a lot like Fedora Workstation, at least until we look under the hood. Ubuntu isn't like that, running Core is a completely different experience from Ubuntu's Desktop and Server editions.
It's not a welcome change. Setting up Ubuntu Core is a test of patience. It doesn't have a system installer, requiring we bootstrap it from another distribution; it doesn't have any on-screen instructions to help users navigate the console-based environment; Core spews systemd status messages over the screen while we are trying to set it up; it requires an on-line account; and it demands we set up authentication using third-party servers rather than allowing us to use local credentials. This last point, relying on Canonical's servers, is especially annoying as it means it's impossible to set up Core in an off-line environment, during a local network outage, or when Canonical's servers go off-line. This is unusually limiting for a Linux distribution.
I'd understand this approach of relying on Ubuntu SSO for authentication if it offered any benefit, but as far as I can tell, it does not. Linking Core to an Ubuntu SSO account doesn't make administration easier, make it faster to deploy machines, or offer any tools for managing multiple deployments. It seems to be over-engineering for the sake of it with no perk for the user.
The experience feels, at this stage, amateurish, and once the distribution is installed, that impression doesn't get a lot better. Core is pleasantly fast and minimal, and I'll happily give it credit for that. However, it's frustrating having only a command line interface from which to work (while Fedora and openSUSE offer optional desktop environments), it's frustrating not having manual pages in such a minimal environment, and it's annoying to find programs (such as useradd) installed when they can't be used.
I will say that Snap, despite its poorly formatted output, works quickly and it works well. We can set up services like Kodi, Transmission, and Nextcloud in seconds. I think this is great and I applaud how easy it is to enable these services on Core. At the same time, allowing Snap to force updates and reboots is a terrible design choice and makes Ubuntu Core feel more like Windows Vista than a proper Linux distribution.
I do think that, once set up and working, Core makes deploying new network services quite quick and easy. However, the same could be said of any Linux distribution capable of running Snap packages and most of those do not impose the same restrictions and barriers during the install process. Core has some good ideas on display, and it's a good platform for showing off Snap, but it feels like it's been hastily thrown together and not tested yet. It feels like too much time was spent designing it in a boardroom by managers and not enough time was spent actually seeing if system administrators and users would actually benefit from its approach.
* * * * *
Visitor supplied rating
Ubuntu has a visitor supplied average rating of: 7.7/10 from 380 review(s).
Have you used Ubuntu? You can leave your own review of the project on our ratings page.
|
| Miscellaneous News (by Jesse Smith) |
Fedora dropping X11 packages for Workstation, Red Hat looking to phase out GRUB, new OpenSSH vulnerability impacts Red Hat systems, UBports introduces new setup utility, FreeBSD speeding up its release cycle
The Fedora team are looking ahead to Fedora 41, which will be released later this year, and are planning to further trim X11 support in favour of Wayland. In particular, GNOME-related X11 packages will be removed from the Fedora Workstation media. "As part of the upstream deprecation and effort to remove X11 support from GNOME, Fedora Workstation media will no longer include the GNOME X11 packages. The packages will remain in the repository (maintained by the GNOME SIG/Workstation WG) for users to manually install at this time." Details of this plan can be found in Fedora's change proposal.
* * * * *
The Red Hat development team is looking at replacing one of the most commonly used pieces of the operating system: the boot loader. Marta Lewandowska writes: "We are working on a new scheme to replace the GRUB bootloader with a fast, secure, Linux-based, user-space solution: nmbl (for no more boot loader).
Most people are familiar with GRUB, a powerful, flexible, fully-featured bootloader that is used on multiple architectures (x86_64, aarch64, ppc64le OpenFirmware). Although GRUB is quite versatile and capable, its features create complexity that is difficult to maintain, and that both duplicate and lag behind the Linux kernel while also creating numerous security holes. On the other hand, the Linux kernel, which has a large developer base, benefits from fast feature development, quick responses to vulnerabilities and greater overall scrutiny.
We (Red Hat boot loader engineering) will present our solution to this problem, which is to use the Linux kernel as its own bootloader. Loaded by the EFI stub on UEFI, and packed into a unified kernel image (UKI), the kernel, initramfs, and kernel command line, contain everything they need to reach the final boot target. All necessary drivers, filesystem support, and networking are already built in and code duplication is avoided."
* * * * *
Last week we reported on an issue in some versions of OpenSSH which could possibly allow an attacker to remotely run code on a vulnerable server. This week we share another, similar issue with OpenSSH that has the interesting characteristic of only existing on a few distributions. Specifically, members of the Red Hat family include a patch which makes some recent versions of OpenSSH vulnerable to remote attackers. "The current understanding is that in those upstream versions cleanup_exit() would not actually call async-signal-unsafe functions under those conditions, but with downstream distribution patches it sometimes does. Specifically, openssh-7.6p1-audit.patch found in Red Hat's package of OpenSSH adds code to cleanup_exit() that exposes the issue. Relevantly, this patch is found in RHEL 9 (and its rebuild/downstream distributions), where the package is based on OpenSSH 8.7p1. The audit patch is also found in Fedora, so the package versions that were based on 8.7p1 and 8.8p1 are affected. Per change log, it appears that out of Fedora releases only 36 and 37 were affected, as well as some updates maybe starting with those for 35 and until those for 37. These versions are now end-of-life, and Fedora 38+ has moved to newer upstream OpenSSH that doesn't make the problematic cleanup_exit() call." Additional information can be found in the discussion thread.
* * * * *
The UBports team revealed in their latest newsletter the project will soon have a new first-run wizard. This new setup utility will include the ability to import information from other devices, such as an iPhone or Android device. "Alfred has been doing some work to create an app for first time setup. The idea is that it will migrate your data into a UT phone, whether the source is another UT phone or an Android device or iPhone. This would operate via USB and that prompt some refinement of USB management on UT, especially with permissions. The source will be released on GitHub when it is ready for assessment."
* * * * *
Colin Percival has announced a few changes to the FreeBSD release and support schedule. "We are making two changes related to the release engineering process: 1. FreeBSD stable branch support durations, starting with FreeBSD 15.x, are being reduced from 5 years to 4 years after the .0 release. 2. A predictable schedule of releases is being established, with a new minor release from one of the supported stable branches occurring most quarters." The new release schedule will allow for more frequent minor updates and features getting pushed out to users quicker while also reducing the number of testing snapshots leading up to each release. Details can be found in the mailing list announcement.
* * * * *
These and other news stories can be found on our Headlines page.
|
| Questions and Answers (by Jesse Smith) |
Hiding files on Linux
Hide-and-seek asks: Is there a way to properly hide files, not just rename them to .something?
DistroWatch answers: To add context to this question, some operating systems (such as DOS and Windows) have a concept of a hidden file. The idea on those platforms is we can make any file or directory hidden by changing a file attribute. A file attribute is a bit of meta data, like permissions or the "last modified" field. On those platforms, enabling the "hidden" attribute will cause the file to not show up in regular directory listings or, by default, in a graphical file manager. Though it is possible to override the defaults to see hidden files and folders on those platforms.
On Linux (and other members of the Unix family) there isn't a direct equivalent to the hidden file attribute. Instead, on Linux any file or directory which has a name that begins with a dot (".") is considered to be hidden by most utilities. There isn't any element of the underlying operating system which hides a file or directory that has a dot prefix in its name, but most file handling utilities will ignore these files by default. As on Windows, Linux utilities (such ls) typically have an option to show hidden files, also known as "dot files".
Some people might wonder why Linux uses this approach, hiding files with a dot prefix, rather than using a file attribute flag. After all, forcing files to begin with a dot prefix means we need to rename a file to mark it as hidden, which might be awkward or require changing scripts or programs that relied on the old name.
I think there are two main reasons the concept of hidden files on Linux hasn't evolved much or resulted in a new hidden attribute flag the user can set. The first is there are very few cases in which we would create a file and then, later, decide it should be hidden. Usually hidden files only make sense when we are creating configuration files or data storage locations the user will not be interacting with directly (.config and .git come to mind).
In other words, hidden files almost exclusively make sense for items which will be accessed by applications and services in the background, not interacted with by the user themselves. Since the user will probably never interact with hidden files and directories directly, the user will probably never manually make a hidden file or need to know its name. Likewise, the user will almost never need to un-hide or change the name of a file that was already hidden and, if they did, we have symbolic links which will handle that task, allowing the original filename to remain unchanged.
Basically, hidden files are almost exclusively the domain of programs storing data users do not need to see or interact with directly, so the naming of the file (and the idea of renaming a hidden file) is pretty much a non-issue.
The second reason Linux doesn't rely on a hidden file attribute is, in the rare case when a user might want to hide a file, it is probably to prevent other users from knowing the file exists. Obviously the person creating the file knows it exists, and there isn't any point in hiding the file from oneself, so that means any hidden file we make ourselves is almost certainly done to hide the file from other users. Hiding files can make a degree of sense on a single-user operating system like DOS and early versions of Windows. However, Unix and Linux have always been multi-user systems and have another, more secure approach to preventing people from looking at our files.
On Linux, if we want to hide a file from other users we can simply place the file in a directory which is not accessible to other users. Or, if we don't mind people knowing the file exists, but want to prevent people from seeing its contents, we can remove read access to the file from other accounts. This can be accomplished with any file manager or the chmod command.
Having a hidden file attribute made sense when people in a home or office were sharing floppy disks and single-user operating systems and wanted to hide the existence of files from each other. However, multi-user systems have more robust ways of protecting data built into the filesystem. Hiding user-generated files is almost never necessary on a multi-user platform like Linux because placing files we don't want others to see in a non-accessible directory or taking away read access provides more robust security.
Should you wish to create a directory where the files contained in the directory are hidden, you can use mkdir and chmod to accomplish this:
mkdir Hidden
chmod u=rwx,g=,o= Hidden
The first command, mkdir, creates the Hidden directory. The chmod command then grants the user who created the directory full permissions (read, write, and access) while people in the user's group and other people on the system get no permissions or access at all. Any files created in the Hidden directory will be visible only to the user who created the Hidden directory. All other users (apart from the system administrator) will not be able to read its contents.
* * * * *
Additional queries and answers can be found in our Questions and Answers archive.
|
| Released Last Week |
NethSecurity 8.1
NethSecurity is a fully-featured open source Linux firewall that streamlines network security deployment in just a few clicks. The project has published a new update to its 8.x series which introduces a connection tracking interface and a user account manager in the web-based interface. "New features: Connections management page: adds interface for managing active network connections tracked by conntrack. MultiWAN add sticky option in rules: introduces sticky option in MultiWAN rules for connection persistence. Great enhancements on LDAP remote database authentication: improves authentication flexibility for Active Directories and other LDAP configurations. DPI signatures for community subscriptions: provides updated DPI signatures for both community and enterprise subscriptions. Expose admin users: adds functionality to convert local users to admin and revoke admin access. Repository access add a subscription authentication proxy: enables access to subscription repository channel after system_key verification." Additional details can be found in the project's release announcement.
Clonezilla Live 3.1.3-11
Clonezilla Live is a Debian-based distribution used for disk and partition cloning. The project's latest release, version 3.1.3-11, introduces updated hardware support and brings Clonezilla Live more in line with Debian's Unstable (Sid) repositories. "The underlying GNU/Linux operating system was upgraded. This release is based on the Debian Sid repository (as of 2024/Jun/28). Linux kernel was updated to 6.9.7-1. Partclone was updated to 0.3.31. Removed package cpufrequtils from lists of live system. It's not in the Debian repo anymore. Removed thin-provisioning-tools from packages list of clonezilla live due to it breaks the dependence. Added package yq, and removed package deborphan in live system. Merged pull request #31 from iamzhaohongxin/patch-1. Update zh_CN.UTF-8. Language file ca_ES was updated. Thanks to René Mérou. Language file de_DE was updated. Thanks to Savi G and Michael Vinzenz. Package live-boot was updated to 1:20240525.drbl1. Package live-config was updated to 11.0.5+drbl3. Set a bigger scrollback for screen in live system. It's easier to debug." Additional information can be found in the project's release announcement.
TrueNAS 24.04.1.1 "SCALE"
TrueNAS is a project which develops network attached storage operating systems. SCALE is the Debian-based branch of the project. TrueNAS SCALE recently received an update which significantly improves input/output performance. "Dragonfish benefits from OpenZFS, Linux, SAMBA improvements, and some TrueNAS optimizations. The performance changes may not be obvious for smaller systems, but larger systems need software performance that scales with core and drive count. Dragonfish has significant improvements in IOPS (virtualization and databases), bandwidth (video and backup), and File Metadata (directory listings). 50% more IOPS: IOPS (Input/Outputs Per Second) is a classic storage metric for transactional workloads like virtual desktops and databases. On the same platform and pool configuration (a TrueNAS M50 with 20 SSDs in 4x 5wZ1) we see 50% higher IOPS with Dragonfish when compared to TrueNAS 13.0." Further details can be found in the project's release announcement and in the release notes.
Qubes OS 4.2.2
The Qubes OS team have announced a new update to the project's security-focused operating system. One of the significant changes in Qubes OS 4.2.2 is an adjustment to how files are transferreed between isolated envirnonments, called qubes. "Qubes 4.2.2 includes a fix for #8332: File-copy qrexec service is overly restrictive. As explained in the issue comments, we introduced a change in Qubes 4.2.0 that caused inter-qube file-copy/move actions to reject filenames containing, e.g., non-Latin characters and certain symbols. The rationale for this change was to mitigate the security risks associated with unusual unicode characters and invalid encoding in filenames, which some software might handle in an unsafe manner and which might cause confusion for users. Such a change represents a trade-off between security and usability. After the change went live, we received several user reports indicating more severe usability problems than we had anticipated. Moreover, these problems were prompting users to resort to dangerous workarounds (such as packing files into an archive format prior to copying) that carry far more risk than the original risk posed by the unrestricted filenames. In addition, we realized that this was a backward-incompatible change that should not have been introduced in a minor release in the first place. Therefore, we have decided, for the time being, to restore the original (pre-4.2) behavior by introducing a new allow-all-names argument for the qubes.Filecopy service. By default, qvm-copy and similar tools will use this less restrictive service (qubes.Filecopy +allow-all-names) whenever they detect any files that would be have been blocked by the more restrictive service (qubes.Filecopy +). If no such files are detected, they will use the more restrictive service." Additional information is available in the 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,033
- Total data uploaded: 44.9TB
|
| Upcoming Releases and Announcements |
|
Summary of expected upcoming releases
|
| Opinion Poll (by Jesse Smith) |
Which immutable distribution is your favourite?
More and more distributions, particularly commercially backed projects, are experimenting with immutable (read-only) filesystems. This week we started with a look at one such project, Ubuntu Core. There are several other immutable distributions from which to choose and we'd like to hear which one you like best.
You can see the results of our previous poll on migrating away from CentOS Linux 7 in our previous edition. All previous poll results can be found in our poll archives.
|
Which immutable distribution is your favourite?
| Endless OS: | 36 (2%) |
| Fedora Silverblue: | 136 (6%) |
| Murena: | 40 (2%) |
| openSUSE Micro: | 76 (4%) |
| rlxos: | 4 (0%) |
| UBports: | 15 (1%) |
| Ubuntu Core: | 16 (1%) |
| Vanilla OS: | 26 (1%) |
| Other: | 64 (3%) |
| I do not like/use immutable distros: | 1727 (81%) |
|
|
| Website News |
New distributions added to waiting list
- AlterOS. AlterOS. AlterOS is a Russian Linux distribution based on the latest stable Linux kernel, developed by ALMI Partner. It is designed for a wide range of applications and to integrate easily into the IT infrastructure of commercial and government organizations.
* * * * *
DistroWatch database summary
* * * * *
This concludes this week's issue of DistroWatch Weekly. The next instalment will be published on Monday, 22 July 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: 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 • Immutable Distros (by Jacob Alexander Tice on 2024-07-15 01:37:06 GMT from United States)
I'm gonna be perfectly honest: I think that outside of embedded systems, immutable distros are a fad. I certainly don't see any benefits. But that's just me.
2 • Immutable Distros (by Ivan on 2024-07-15 01:47:00 GMT from Italy)
I've seen a high percentage of people who don't use/don't like immutable distributions. It would have been interesting to see the two options separated. Personally I prefer to have full control of my system, both to install applications and to apply custom configurations. Limitations bother me.
On the other hand, I admit that if someone intends to "market" a Linux distro they are the best solution in this sense: less damage from users = less technical support.
3 • Immutable Distros (by Vinfall on 2024-07-15 02:05:58 GMT from Hong Kong)
The thing is, almost every VM software allows you to set a disk to immutable status. In the worst case, you can just set RO flag on the disk file itself. I just don't buy the story of immutable distros since literally every OS can be immutabe this way. Moreover, DOS (aka. Disk Operating System), can also be immutable. Immutable is a feature from hell as old as computer. How come it resurrects from the tomb and becomes popular? Of course, official support is better but I can't see how that can change the play dramatically.
4 • immutable distribution is not the only way (by Jorge on 2024-07-15 02:57:39 GMT from Argentina)
OverlayFS have some similar abilities. Am I Right?
Any Live Distribution is using this ability to run a complete packed OS
Maybe with a easier approach we can just adding packages over the OS layers without touching the filesystem.
5 • Immutable distributions (by Bobbie Sellers on 2024-07-15 03:04:33 GMT from United States)
I don't really get it.
What makes an immutable System different from a simple old-fashioned Rolling Release?
I don't think i have seen a review of the IS that is happy with the result.
In some uses they might be good but for everyday they are awkward.
B. Sellers
6 • @ 4 • immutable distribution is not the only way (by Because: reason on 2024-07-15 03:29:43 GMT from New Zealand)
correct.
And as a "bonus", they can be made to be updateable and have functionality expanded by enabling persistence ( if your distro of choice allows this. ) Standard packages can be added and then removed in the usual way, including kernels if required, again distro dependent.
I currently have 3 on this hardware. The system partitions (combined root / home) are from 7-10GB, with separate persistence partitions for each .
!!!!! just do not try to remove a package from the overlayFS !!!!!
7 • Immutable Distros (by Reyfer on 2024-07-15 05:16:16 GMT from Venezuela)
To me, personally, immutable distros "could" be good for enterprises or government offices, but for me as a private user, I prefer the full freedom to "break" my system if I want to and learn how to fix it, so.....
8 • immutable distros (by user on 2024-07-15 05:21:16 GMT from Bulgaria)
I don't like and will not use immutable distros - ever!
I have tried the immutable openSUSE Micro and I'm horrified.
Immutability is a denial to choice - your choice of init system, file-system, kernel version, compilers version, containerization, desktop flavor and richness, etc. You are left on the mercy of the distro developers to chose for you what they seem fit for the system components and core system build, and these you are not allowed to modify. It is an Android like experience, where the user loses entirely control over the OS, and is allowed only to interact with it by applications. It is a distro specific technologies selections lock-in, worse even than Windows. Immutability is impractical in Deskop use, many restarts are needed to modify your own personal settings if allowed.
On the positive side my immutability experience reminded me how truly free the classic Linux architecture is.
9 • Immutable Distros (by Bin on 2024-07-15 05:36:00 GMT from United Kingdom)
To a large extent IDs are not going to appeal to folks who enjoy Distrowatch - but then they are not the market.
However, if you look at EndlessOS, their web site and how they position their offering then you get a better idea of where it does work. There are linux savvy people who do run Endless on a number of family machines.
If you are not used to being able to alter your working environment and just need simple tools for day to day browsing, email, games etc then an immutable system can be just what is needed.
Why not try putting the base version of EOS into a VM and looking at it from a different point of view?
10 • Immutable OS (by Flattermann on 2024-07-15 06:25:54 GMT from Germany)
In practice, immutable distros were a terrible experience for me (no out-of-the-box experience; setting up external devices such as printers, multiple screens; interacting with colleagues; updates became a process where you weren't sure whether everything was still working). Personally, I see a security gain, but not a huge one. The fact that you have an immutable OS does not mean that it is unassailable. Downloading apps from the Snapstore or Flathub, for example, is practical, but as a user you have to trust that everything works perfectly there, just like in a classic repository. The internet and its risks will always be a problem. The router is becoming increasingly interesting for hackers, not the computer and its OS, because the bad guys adapt.
11 • Bootloader in Fedora (by Pumpino on 2024-07-15 07:05:24 GMT from Australia)
I decided to install Fedora 40 last night after playing with the Cinnamon live system for a while. Fedora correctly added a grub entry for my Ubuntu partition and replaced Ubuntu's grub, which was expected. However, it didn't add an entry for itself. I had to boot into Ubuntu, run update-grub to detect Fedora and then replace Fedora's grub with Ubuntu's grub. Maybe Red Hat should look at mastering grub before it moves to an alternative.
12 • Immutable distros poll (by SuperOscar on 2024-07-15 08:13:34 GMT from Finland)
I wonder why NixOS and GNU Guix were not listed as alternatives? AFAIK they’ve been around for longer than any of those listed.
13 • Hidden files (by James on 2024-07-15 09:30:17 GMT from United States)
If I had a file I wanted to keep prying eyes from I would use 7z to compress it, hied the file name and password protect it.
As far as system hidden files I see little difference between putting a . before the file or checking a box to hide the file. Both are easily changed and found by checking see hidden files in the file browser.
14 • The Dystopias Materialising While We Speak (by Jo on 2024-07-15 09:32:58 GMT from United Kingdom)
>"...will not proceed without a valid SSO account e-mail address"
The cancer continues: corporate-agenda "Surveillance Capitalism" in the nominally-FLOSS corpus.
[https://en.wikipedia.org/wiki/The_Age_of_Surveillance_Capitalism]
15 • Nix and Guix (by Jesse on 2024-07-15 10:13:38 GMT from Canada)
@12: "I wonder why NixOS and GNU Guix were not listed as alternatives?"
Because neither Nix or Guix are, in any way, immutable distributions. They would have no reason to be in the list.
16 • Hidden files (by Jeffrey on 2024-07-15 10:29:16 GMT from Czechia)
It interesting to see an article on this topic without mentioning Rob Pike's "A lesson in shortcuts".
While the article was originally posted on Google+, and is thus unavailable, there are many re-posts, such as the one here: https://glenda.0x46.net/articles/dotfiles/ Long story short: in all likelihood, the very existence of dot-entries (let alone their being "hidden") was totally unintended, and it was a result of "programmer laziness".
> so the naming of the file (and the idea of renaming a hidden file) is pretty much a non-issue.
This is clearly false. No matter how rarely you might need to include dot-files and dot-directories in the arguments of a command, mayhem ensues. (You have to go full-RE just to include them, but of course you can't just use an RE like "all entries beginning with '.'", because that will include ".." and all its entries....) Another issue is that dot-files and dot-directories enable (and almost encourage) "littering": throwing countless files and directories under $HOME, under the caring protection of that leading dot, without regard to the number of (sub)directories, directory structure, or automatic removal of the files/directories once they are not needed. A third (and related) issue is complete inconsistency: some programs put their files right in $HOME (e.g. config files could be ~/.foobarrc or ~/.foobar.conf), some use their own directory (e.g. ~/.foobar/), some use one or more of the ~.config, ~/.local and ~/.cache directories, again, often pretty inconsistently. (E.g. some programs put caches or other non-config data under ~/.config, which is clearly wrong.) Some programs put their executables in ~~/.local/bin, some under their own subdirectory (foobar/bin) in some dot-directory of $HOME, some may even put it in ~/bin -- and then some of these programs will add this directory to your $PATH, whether you want it or not, whether it is already in $PATH or not. And then you have to deal with the same program providing alternatives for the same file, e.g. the Nano user config can be in ~/.nanorc or in ~/.config/nano/nanorc. (If you like your current Nano config and want to back it up, but it turns out both files exist [littering, right?], which one do you back up? You have to work just to find out...)
The proper, correct way to do it would be to completely do away with dot-entries, and use some parts of the FHS under $HOME as well. E.g. it makes complete sense that if config files are under /etc/, then user config files are under $HOME/etc/. User caches should go under ~/var/cache/, and shell and other histories should go under ~/var/hist/ or similar. (User logs, if not sent to the system log, should definitely go under ~/var/log/.) Also, programs should always offer the user to customise the program's file and directory locations, in case the user doesn't like the defaults; programs should also offer to clean up their files when being uninstalled, and leave a script for the user to later do the same.
17 • I like the one I use: Murena (by Biff on 2024-07-15 12:29:26 GMT from Sweden)
I mean its in the list - and its technically an immutable distro but for phones - and it does its job perfectly. For a phone you get a lot of advantages and tend not to stumble on all the extra abstractions that has to be done I suppose
18 • Surveillance Capitalism (by Friar Tux on 2024-07-15 13:29:59 GMT from Canada)
@14 (Jo) Surveillance Capitalism has been around long before computers ever came along - since the invention of pencil and paper. Computers just made it a whole lot simpler. I remember a store in Montreal, Que., Canada, (in the 1960s) where the owner knew every purchase my Mother made and always had the stuff ready when she walked in. (No, Mom didn't call ahead on the telephone. That was unheard of at the time.) I used to walk into the local candy store with my two bits and the proprietor already had my favourite candy ready. Surveillance Capitalism is actually a "new" thing, just a new name.
19 • Surveillance Capitalism was NOT in the 1960s (by doesntmatter on 2024-07-15 13:53:44 GMT from Germany)
@18 (Friar Tux) What you describe is not the same, due to the completely different scope.
A single store owner remembering the habits of his customers (or even documenting them) is in no way comparable to what huge platforms and tech companies do today. The store owner you mentioned surely did not sell his knowledge to the biggest ad companies in the world, he used it himself. That is a huge difference.
And he did not have the ability - or probably even the intent - to enforce the concept of "no privacy" in totalitarian fashion. One could even argue that his customers consented to this data collection by using his store, since they obviously had alternatives. And they could agree safely, since the information would not be shared uncontrollably.
20 • immutable distributions (by Pogi Americano on 2024-07-15 20:18:22 GMT from United States)
I'm not a real "techie" person, at least not yet, I came to Linux because of the promise that I could get the source code and read books, go to classes and learn by poking around, changing a few things and if it works, I could share it with the world and not worry about licenses and copy writes or breaking some law. This "immutable" stuff worries me. It sounds like, "look but don't touch" ... Again, I could be wrong in my thinking. I'm worried that some day "immutable" will become like Microsoft and Apple, with source code locked away in a vault somewhere. I do praise the Linux community for trying stuff and letting everyone play with it, just don't go the way of Microsoft and Apple. OR Red Hat, yes, I know they are an open source company, but they do have licenses that allow only a certain amount of people to use it, and can you just download the latest source code? ... Just my 2 cents.
21 • Immutable distros (by penguinx86 on 2024-07-16 03:38:55 GMT from United States)
I like the idea of Fedora Silverblue. I tried it and it works well. Seems like it could prevent some malware. But I quit using it because I don't like Gnome. It would be better if there was a choice of desktop environments like Xfce.
22 • Immutable distro (by TheCatboy on 2024-07-16 05:46:33 GMT from United States)
I run SteamOS and love it
23 • Immutable distros (by De Schatberg on 2024-07-16 10:06:24 GMT from The Netherlands)
@21 (by penguinx86 from United States)
"I like the idea of Fedora Silverblue. ... It would be better if there was a choice of desktop environments..."
There is, but fortunately no XFCE. There are Budgie and KDE versions, and the somewhat freaky Sway.
24 • Immutable distro (by andrabt on 2024-07-16 11:12:07 GMT from Indonesia)
I don't think that everyone here know what immutable distro is (and why they existed). So in everyone point of view may differs because feel that they don't need them.
I enjoy Linux and use it from 2005. I've tried many distro, and several of them are my favourite such as EndeavoursOS and Solus. The problem is when I use it above a year, sometimes I encounter bad update and need complex fixes. Sometimes I don't have time to do the fixes while I need to use my machine ASAP.
Immutable distro brings something like atomic updates, which we can rolled back to previous state without hassle. Yes, I know that snapper and btrfs provide that too (and that's cool). But I prefer distro which just works when I need it, even though I like to troubleshoot myself too (while it must not differ that much from standard state).
Currently I use NixOS and Fedora Silverblue (as my second backup and my playground too).
25 • Mozilla & UEFI (by De Schatberg on 2024-07-16 12:30:37 GMT from The Netherlands)
By the way, have you checked your Firefox settings after updating to version 128? Since the update, Mozilla has been collecting user data for its newly acquired ad company. This feature is automatically enabled unless you manually disable it in the preferences.
I don't know how many of you remember or bought the article whose link I posted a few weeks ago, but it looks like Microsoft's UEFI changes are starting to hit Linux users. If you don't use Secure Boot, you may get firmware update errors with UEFI and CSM mode.
As always, it depends on your browser version and distribution.
26 • Immutable Distros (by npaladin2000 on 2024-07-16 13:59:19 GMT from United States)
You probably should have used Fedora Atomic rather than Fedora Silverblue.
27 • immutable useless (by rhtoras on 2024-07-16 16:42:56 GMT from Greece)
No usecase scenario for immutable distros. You have to understand: Linux and Unix never die. systemD will die...
gates win postponed for another day...
No benefit for these types of distros to the end user. Are they offering something that normal distros can't do ? I doubt. And we can see from the answers that no all users know 100% what these are and what they can do. To sum it up: immutable distros share similarities with windows (update system, installation methods e.t.c) and this is why people do not like them. NO use of apt ON debian based ? This is not linux way of doing things.
28 • @Jesse (by Débarqué on 2024-07-17 11:17:57 GMT from France)
How come have you got the idea to try running Ubuntu Core as a desktop distro, while you DID know Ubuntu guys intented it ONLY "for deploying IoT and embedded systems"?
IoT and embedded systems are typically headless systems (no screen, no keyboard, no mouse...) with a dedicated application program on top of it.
Besides, why such a thing needs to log in to Ubuntu SSO to install makes no sense. Especially embedded systems are often purposefully deprived of any network connection.
I guess Ubuntu guys do not to expect you to install it on a device of a space probe!
I advised you do not install Ubuntu Core on sensitive production devices either. Imagine parts of a nuclear plant monitoring system preconfigured with an Internet access... - creepy.
29 • (follows previous comment) (by Débarqué on 2024-07-17 11:23:10 GMT from France)
Actually, an Internet connexion on your surveillance camera is already creepy.
30 • Embedded or not? (by De Schatberg on 2024-07-17 12:08:04 GMT from The Netherlands)
@28 (by Débarqué from France)
On the other side, probably the biggest part of all embedded systems are connected to the internet—think of online payment systems.
31 • My fav Immutables (by viamoiam on 2024-07-18 13:15:10 GMT from Canada)
So many great immutable' distro's were not mentioned. Well technically not just 'immutable' as they can be layered. My favourites are great for gaming like Steam OS for Steam Deck, and for everything else ChimeraOS or Bazzite. Both give a console experience if wanted and can work with DeckyLoader.
I was surprised everything from Universal Blue wasn't mentioned seeing as they are about atomic desktops. https://universal-blue.org/ only one fedora Atomic desktop was mentioned out of the 4 from the official list from Fedora. Okay, okay not just immutable, but better as it solves my issues with immutable distro customization by letting me add my layer on top.
Even MacOS or Windows needs to be customized and have the customization be easily reproduced. I can't restore from a backup so easily on an immutable but I can generate the updated layer for atomic. Stuff like Bazzite can be more easily updated and the customization regenerated or the base switched out from say gnome to kde for ex.
32 • Global IT outage (by linuxuser on 2024-07-19 14:31:37 GMT from Greece)
Linux systems are not affected by the Global IT outage.
Good news.
Number of Comments: 32
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 1163 (2026-03-09): KaOS 2026.02, TinyCore 17.0, NuTyX 26.02.2, Would one big collection of packages help?, Guix offers 64-bit Hurd options, Linux communities discuss age delcaration laws, Mint unveils new screensaver for Cinnamon, Redox ports new COSMIC features |
| • Issue 1162 (2026-03-02): AerynOS 2026.01, anti-virus and firewall tools, Manjaro fixes website certificate, Ubuntu splits firmware package, jails for NetBSD, extended support for some Linux kernel releases, Murena creating a map app |
| • Issue 1161 (2026-02-23): The Guix package manager, quick Q&As, Gentoo migrating its mirrors, Fedora considers more informative kernel panic screens, GhostBSD testing alternative X11 implementation, Asahi makes progress with Apple M3, NetBSD userland ported, FreeBSD improves web-based system management |
| • Issue 1160 (2026-02-16): Noid and AgarimOS, command line tips, KDE Linux introduces delta updates, Redox OS hits development milestone, Linux Mint develops a desktop-neutral account manager, sudo developer seeks sponsorship |
| • Issue 1159 (2026-02-09): Sharing files on a network, isolating processes on Linux, LFS to focus on systemd, openSUSE polishes atomic updates, NetBSD not likely to adopt Rust code, COSMIC roadmap |
| • Issue 1158 (2026-02-02): Manjaro 26.0, fastest filesystem, postmarketOS progress report, Xfce begins developing its own Wayland window manager, Bazzite founder interviewed |
| • Issue 1157 (2026-01-26): Setting up a home server, what happened to convergence, malicious software entering the Snap store, postmarketOS automates hardware tests, KDE's login manager works with systemd only |
| • Issue 1156 (2026-01-19): Chimera Linux's new installer, using the DistroWatch Torrent Corner, new package tools for Arch, Haiku improves EFI support, Redcore streamlines branches, Synex introduces install-time ZFS options |
| • Issue 1155 (2026-01-12): MenuetOS, CDE on Sparky, iDeal OS 2025.12.07, recommended flavour of BSD, Debian seeks new Data Protection Team, Ubuntu 25.04 nears its end of life, Google limits Android source code releases, Fedora plans to replace SDDM, Budgie migrates to Wayland |
| • Issue 1154 (2026-01-05): postmarketOS 25.06/25.12, switching to Linux and educational resources, FreeBSD improving laptop support, Unix v4 available for download, new X11 server in development, CachyOS team plans server edtion |
| • Issue 1153 (2025-12-22): Best projects of 2025, is software ever truly finished?, Firefox to adopt AI components, Asahi works on improving the install experience, Mageia presents plans for version 10 |
| • Issue 1152 (2025-12-15): OpenBSD 7.8, filtering websites, Jolla working on a Linux phone, Germany saves money with Linux, Ubuntu to package AMD tools, Fedora demonstrates AI troubleshooting, Haiku packages Go language |
| • Issue 1151 (2025-12-08): FreeBSD 15.0, fun command line tricks, Canonical presents plans for Ubutnu 26.04, SparkyLinux updates CDE packages, Redox OS gets modesetting driver |
| • Issue 1150 (2025-12-01): Gnoppix 25_10, exploring if distributions matter, openSUSE updates tumbleweed's boot loader, Fedora plans better handling of broken packages, Plasma to become Wayland-only, FreeBSD publishes status report |
| • Issue 1149 (2025-11-24): MX Linux 25, why are video drivers special, systemd experiments with musl, Debian Libre Live publishes new media, Xubuntu reviews website hack |
| • Issue 1148 (2025-11-17): Zorin OS 18, deleting a file with an unusual name, NetBSD experiments with sandboxing, postmarketOS unifies its documentation, OpenBSD refines upgrades, Canonical offers 15 years of support for Ubuntu |
| • Issue 1147 (2025-11-10): Fedora 43, the size and stability of the Linux kernel, Debian introducing Rust to APT, Redox ports web engine, Kubuntu website off-line, Mint creates new troubleshooting tools, FreeBSD improves reproducible builds, Flatpak development resumes |
| • Issue 1146 (2025-11-03): StartOS 0.4.0, testing piped commands, Ubuntu Unity seeks help, Canonical offers Ubuntu credentials, Red Hat partners with NVIDIA, SUSE to bundle AI agent with SLE 16 |
| • Issue 1145 (2025-10-27): Linux Mint 7 "LMDE", advice for new Linux users, AlmaLinux to offer Btrfs, KDE launches Plasma 6.5, Fedora accepts contributions written by AI, Ubuntu 25.10 fails to install automatic updates |
| • Issue 1144 (2025-10-20): Kubuntu 25.10, creating and restoring encrypted backups, Fedora team debates AI, FSF plans free software for phones, ReactOS addresses newer drivers, Xubuntu reacts to website attack |
| • Issue 1143 (2025-10-13): openSUSE 16.0 Leap, safest source for new applications, Redox introduces performance improvements, TrueNAS Connect available for testing, Flatpaks do not work on Ubuntu 25.10, Kamarada plans to switch its base, Solus enters new epoch, Frugalware discontinued |
| • Issue 1142 (2025-10-06): Linux Kamarada 15.6, managing ZIP files with SQLite, F-Droid warns of impact of Android lockdown, Alpine moves ahead with merged /usr, Cinnamon gets a redesigned application menu |
| • Issue 1141 (2025-09-29): KDE Linux and GNOME OS, finding mobile flavours of Linux, Murena to offer phones with kill switches, Redox OS running on a smartphone, Artix drops GNOME |
| • Issue 1140 (2025-09-22): NetBSD 10.1, avoiding AI services, AlmaLinux enables CRB repository, Haiku improves disk access performance, Mageia addresses service outage, GNOME 49 released, Linux introduces multikernel support |
| • Issue 1139 (2025-09-15): EasyOS 7.0, Linux and central authority, FreeBSD running Plasma 6 on Wayland, GNOME restores X11 support temporarily, openSUSE dropping BCacheFS in new kernels |
| • Issue 1138 (2025-09-08): Shebang 25.8, LibreELEC 12.2.0, Debian GNU/Hurd 2025, the importance of software updates, AerynOS introduces package sets, postmarketOS encourages patching upstream, openSUSE extends Leap support, Debian refreshes Trixie media |
| • Issue 1137 (2025-09-01): Tribblix 0m37, malware scanners flagging Linux ISO files, KDE introduces first-run setup wizard, CalyxOS plans update prior to infrastructure overhaul, FreeBSD publishes status report |
| • Issue 1136 (2025-08-25): CalyxOS 6.8.20, distros for running containers, Arch Linux website under attack,illumos Cafe launched, CachyOS creates web dashboard for repositories |
| • Issue 1135 (2025-08-18): Debian 13, Proton, WINE, Wayland, and Wayback, Debian GNU/Hurd 2025, KDE gets advanced Liquid Glass, Haiku improves authentication tools |
| • Issue 1134 (2025-08-11): Rhino Linux 2025.3, thoughts on malware in the AUR, Fedora brings hammered websites back on-line, NetBSD reveals features for version 11, Ubuntu swaps some command line tools for 25.10, AlmaLinux improves NVIDIA support |
| • Issue 1133 (2025-08-04): Expirion Linux 6.0, running Plasma on Linux Mint, finding distros which support X11, Debian addresses 22 year old bug, FreeBSD discusses potential issues with pkgbase, CDE ported to OpenBSD, Btrfs corruption bug hitting Fedora users, more malware found in Arch User Repository |
| • Issue 1132 (2025-07-28): deepin 25, wars in the open source community, proposal to have Fedora enable Flathub repository, FreeBSD plans desktop install option, Wayback gets its first release |
| • Issue 1131 (2025-07-21): HeliumOS 10.0, settling on one distro, Mint plans new releases, Arch discovers malware in AUR, Plasma Bigscreen returns, Clear Linux discontinued |
| • Issue 1130 (2025-07-14): openSUSE MicroOS and RefreshOS, sharing aliases between computers, Bazzite makes Bazaar its default Flatpak store, Alpine plans Wayback release, Wayland and X11 benchmarked, Red Hat offers additional developer licenses, openSUSE seeks feedback from ARM users, Ubuntu 24.10 reaches the end of its life |
| • Issue 1129 (2025-07-07): GLF OS Omnislash, the worst Linux distro, Alpine introduces Wayback, Fedora drops plans to stop i686 support, AlmaLinux builds EPEL repository for older CPUs, Ubuntu dropping existing RISC-V device support, Rhino partners with UBports, PCLinuxOS recovering from website outage |
| • Issue 1128 (2025-06-30): AxOS 25.06, AlmaLinux OS 10.0, transferring Flaptak bundles to off-line computers, Ubuntu to boost Intel graphics performance, Fedora considers dropping i686 packages, SDesk switches from SELinux to AppArmor |
| • Issue 1127 (2025-06-23): LastOSLinux 2025-05-25, most unique Linux distro, Haiku stabilises, KDE publishes Plasma 6.4, Arch splits Plasma packages, Slackware infrastructure migrating |
| • Issue 1126 (2025-06-16): SDesk 2025.05.06, renewed interest in Ubuntu Touch, a BASIC device running NetBSD, Ubuntu dropping X11 GNOME session, GNOME increases dependency on systemd, Google holding back Pixel source code, Nitrux changing its desktop, EFF turns 35 |
| • Issue 1125 (2025-06-09): RHEL 10, distributions likely to survive a decade, Murena partners with more hardware makers, GNOME tests its own distro on real hardware, Redox ports GTK and X11, Mint provides fingerprint authentication |
| • Issue 1124 (2025-06-02): Picking up a Pico, tips for protecting privacy, Rhino tests Plasma desktop, Arch installer supports snapshots, new features from UBports, Ubuntu tests monthly snapshots |
| • Issue 1123 (2025-05-26): CRUX 3.8, preventing a laptop from sleeping, FreeBSD improves laptop support, Fedora confirms GNOME X11 session being dropped, HardenedBSD introduces Rust in userland build, KDE developing a virtual machine manager |
| • Issue 1122 (2025-05-19): GoboLinux 017.01, RHEL 10.0 and Debian 12 updates, openSUSE retires YaST, running X11 apps on Wayland |
| • Issue 1121 (2025-05-12): Bluefin 41, custom file manager actions, openSUSE joins End of 10 while dropping Deepin desktop, Fedora offers tips for building atomic distros, Ubuntu considers replacing sudo with sudo-rs |
| • 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 |
| • 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 | 
ShredOS
ShredOS is a small live Linux distribution whose sole purpose is to securely erase the contents of disks. It can boot from a USB device, CD or DVD and it supports both BIOS and UEFI booting. The system boots directly into nwipe, a program that securely erases the contents of block devices; it can wipe a single drive or multiple disks in parallel. After booting the system, the user can select a disk to erase, together with one of the various erasure methods, such as "Fill With Zeros", "Fill With Ones", RCMP TSSIT OPS-II, DoD, Gutmann Wipe, PRNG Stream, Schneier Wipe, BMB21-2019 and others. The nwipe program automatically starts its ncurses-based interface in the first virtual terminal (ALT-F1), while other useful tools, such as hdparm, smartmontools and hexeditor can be run in the second virtual terminal (ALT-F2). ShredOS is available in "Standard" and "Lite" editions, with the latter able to run on computers with as little as 512 MB of RAM.
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.
|
|
• 
• 
• 
• 
• 
• 
• 
