 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 297 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 |
|
|
|
| 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 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 |
| • Issue 1055 (2024-01-29): CNIX OS 231204, distributions patching packages the most, Gentoo team presents ongoing work, UBports introduces connectivity and battery improvements, interview with Haiku developer |
| • Issue 1054 (2024-01-22): Solus 4.5, comparing dd and cp when writing ISO files, openSUSE plans new major Leap version, XeroLinux shutting down, HardenedBSD changes its build schedule |
| • Issue 1053 (2024-01-15): Linux AI voice assistants, some distributions running hotter than others, UBports talks about coming changes, Qubes certifies StarBook laptops, Asahi Linux improves energy savings |
| • Issue 1052 (2024-01-08): OpenMandriva Lx 5.0, keeping shell commands running when theterminal closes, Mint upgrades Edge kernel, Vanilla OS plans big changes, Canonical working to make Snap more cross-platform |
| • Issue 1051 (2024-01-01): Favourite distros of 2023, reloading shell settings, Asahi Linux releases Fedora remix, Gentoo offers binary packages, openSUSE provides full disk encryption |
| • Issue 1050 (2023-12-18): rlxos 2023.11, renaming files and opening terminal windows in specific directories, TrueNAS publishes ZFS fixes, Debian publishes delayed install media, Haiku polishes desktop experience |
| • Issue 1049 (2023-12-11): Lernstick 12, alternatives to WINE, openSUSE updates its branding, Mint unveils new features, Lubuntu team plans for 24.04 |
| • Issue 1048 (2023-12-04): openSUSE MicroOS, the transition from X11 to Wayland, Red Hat phasing out X11 packages, UBports making mobile development easier |
| • Issue 1047 (2023-11-27): GhostBSD 23.10.1, Why Linux uses swap when memory is free, Ubuntu Budgie may benefit from Wayland work in Xfce, early issues with FreeBSD 14.0 |
| • Issue 1046 (2023-11-20): Slackel 7.7 "Openbox", restricting CPU usage, Haiku improves font handling and software centre performance, Canonical launches MicroCloud |
| • Issue 1045 (2023-11-13): Fedora 39, how to trust software packages, ReactOS booting with UEFI, elementary OS plans to default to Wayland, Mir gaining ability to split work across video cards |
| • 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 | 
Nature's Linux
Nature's Linux was a Linux-based operating system developed by Japan's Nature's Linux Alliance. Its main focus was security.
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.
|
|
• 
• 
• 
• 
• 
• 
• 
