 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 328 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 |
| • Ussye 1118 (2025-04-21): Fedora 42, strange characters in Vim, Nitrux introduces new package tools, Fedora extends reproducibility efforts, PINE64 updates multiple devices running Debian |
| • Issue 1117 (2025-04-14): Shebang 25.0, EndeavourOS 2025.03.19, running applications from other distros on the desktop, Debian gets APT upgrade, Mint introduces OEM options for LMDE, postmarketOS packages GNOME 48 and COSMIC, Redox testing USB support |
| • Issue 1116 (2025-04-07): The Sense HAT, Android and mobile operating systems, FreeBSD improves on laptops, openSUSE publishes many new updates, Fedora appoints new Project Leader, UBports testing VoLTE |
| • Issue 1115 (2025-03-31): GrapheneOS 2025, the rise of portable package formats, MidnightBSD and openSUSE experiment with new package management features, Plank dock reborn, key infrastructure projects lose funding, postmarketOS to focus on reliability |
| • Issue 1114 (2025-03-24): Bazzite 41, checking which processes are writing to disk, Rocky unveils new Hardened branch, GNOME 48 released, generating images for the Raspberry Pi |
| • Issue 1113 (2025-03-17): MocaccinoOS 1.8.1, how to contribute to open source, Murena extends on-line installer, Garuda tests COSMIC edition, Ubuntu to replace coreutils with Rust alternatives, Chimera Linux drops RISC-V builds |
| • Issue 1112 (2025-03-10): Solus 4.7, distros which work with Secure Boot, UBports publishes bug fix, postmarketOS considers a new name, Debian running on Android |
| • Issue 1111 (2025-03-03): Orbitiny 0.01, the effect of Ubuntu Core Desktop, Gentoo offers disk images, elementary OS invites feature ideas, FreeBSD starts PinePhone Pro port, Mint warns of upcoming Firefox issue |
| • Issue 1110 (2025-02-24): iodeOS 6.0, learning to program, Arch retiring old repositories, openSUSE makes progress on reproducible builds, Fedora is getting more serious about open hardware, Tails changes its install instructions to offer better privacy, Murena's de-Googled tablet goes on sale |
| • Issue 1109 (2025-02-17): Rhino Linux 2025.1, MX Linux 23.5 with Xfce 4.20, replacing X.Org tools with Wayland tools, GhostBSD moving its base to FreeBSD -RELEASE, Redox stabilizes its ABI, UBports testing 24.04, Asahi changing its leadership, OBS in dispute with Fedora |
| • Issue 1108 (2025-02-10): Serpent OS 0.24.6, Aurora, sharing swap between distros, Peppermint tries Void base, GTK removinglegacy technologies, Red Hat plans more AI tools for Fedora, TrueNAS merges its editions |
| • Issue 1107 (2025-02-03): siduction 2024.1.0, timing tasks, Lomiri ported to postmarketOS, Alpine joins Open Collective, a new desktop for Linux called Orbitiny |
| • Issue 1106 (2025-01-27): Adelie Linux 1.0 Beta 6, Pop!_OS 24.04 Alpha 5, detecting whether a process is inside a virtual machine, drawing graphics to NetBSD terminal, Nix ported to FreeBSD, GhostBSD hosting desktop conference |
| • Issue 1105 (2025-01-20): CentOS 10 Stream, old Flatpak bundles in software centres, Haiku ports Iceweasel, Oracle shows off debugging tools, rsync vulnerability patched |
| • Issue 1104 (2025-01-13): DAT Linux 2.0, Silly things to do with a minimal computer, Budgie prepares Wayland only releases, SteamOS coming to third-party devices, Murena upgrades its base |
| • Issue 1103 (2025-01-06): elementary OS 8.0, filtering ads with Pi-hole, Debian testing its installer, Pop!_OS faces delays, Ubuntu Studio upgrades not working, Absolute discontinued |
| • Issue 1102 (2024-12-23): Best distros of 2024, changing a process name, Fedora to expand Btrfs support and releases Asahi Remix 41, openSUSE patches out security sandbox and donations from Bottles while ending support for Leap 15.5 |
| • Issue 1101 (2024-12-16): GhostBSD 24.10.1, sending attachments from the command line, openSUSE shows off GPU assignment tool, UBports publishes security update, Murena launches its first tablet, Xfce 4.20 released |
| • Issue 1100 (2024-12-09): Oreon 9.3, differences in speed, IPFire's new appliance, Fedora Asahi Remix gets new video drivers, openSUSE Leap Micro updated, Redox OS running Redox OS |
| • Issue 1099 (2024-12-02): AnduinOS 1.0.1, measuring RAM usage, SUSE continues rebranding efforts, UBports prepares for next major version, Murena offering non-NFC phone |
| • Issue 1098 (2024-11-25): Linux Lite 7.2, backing up specific folders, Murena and Fairphone partner in fair trade deal, Arch installer gets new text interface, Ubuntu security tool patched |
| • Issue 1097 (2024-11-18): Chimera Linux vs Chimera OS, choosing between AlmaLinux and Debian, Fedora elevates KDE spin to an edition, Fedora previews new installer, KDE testing its own distro, Qubes-style isolation coming to FreeBSD |
| • Issue 1096 (2024-11-11): Bazzite 40, Playtron OS Alpha 1, Tucana Linux 3.1, detecting Screen sessions, Redox imports COSMIC software centre, FreeBSD booting on the PinePhone Pro, LXQt supports Wayland window managers |
| • Issue 1095 (2024-11-04): Fedora 41 Kinoite, transferring applications between computers, openSUSE Tumbleweed receives multiple upgrades, Ubuntu testing compiler optimizations, Mint partners with Framework |
| • Issue 1094 (2024-10-28): DebLight OS 1, backing up crontab, AlmaLinux introduces Litten branch, openSUSE unveils refreshed look, Ubuntu turns 20
| | • Issue 1093 (2024-10-21): Kubuntu 24.10, atomic vs immutable distributions, Debian upgrading Perl packages, UBports adding VoLTE support, Android to gain native GNU/Linux application support |
| • Issue 1092 (2024-10-14): FunOS 24.04.1, a home directory inside a file, work starts of openSUSE Leap 16.0, improvements in Haiku, KDE neon upgrades its base |
| • Issue 1091 (2024-10-07): Redox OS 0.9.0, Unified package management vs universal package formats, Redox begins RISC-V port, Mint polishes interface, Qubes certifies new laptop |
| • Issue 1090 (2024-09-30): Rhino Linux 2024.2, commercial distros with alternative desktops, Valve seeks to improve Wayland performance, HardenedBSD parterns with Protectli, Tails merges with Tor Project, Quantum Leap partners with the FreeBSD Foundation |
| • Issue 1089 (2024-09-23): Expirion 6.0, openKylin 2.0, managing configuration files, the future of Linux development, fixing bugs in Haiku, Slackware packages dracut |
| • Issue 1088 (2024-09-16): PorteuX 1.6, migrating from Windows 10 to which Linux distro, making NetBSD immutable, AlmaLinux offers hardware certification, Mint updates old APT tools |
| • Issue 1087 (2024-09-09): COSMIC desktop, running cron jobs at variable times, UBports highlights new apps, HardenedBSD offers work around for FreeBSD change, Debian considers how to cull old packages, systemd ported to musl |
| • Issue 1086 (2024-09-02): Vanilla OS 2, command line tips for simple tasks, FreeBSD receives investment from STF, openSUSE Tumbleweed update can break network connections, Debian refreshes media |
| • Issue 1085 (2024-08-26): Nobara 40, OpenMandriva 24.07 "ROME", distros which include source code, FreeBSD publishes quarterly report, Microsoft updates breaks Linux in dual-boot environments |
| • Issue 1084 (2024-08-19): Liya 2.0, dual boot with encryption, Haiku introduces performance improvements, Gentoo dropping IA-64, Redcore merges major upgrade |
| • Issue 1083 (2024-08-12): TrueNAS 24.04.2 "SCALE", Linux distros for smartphones, Redox OS introduces web server, PipeWire exposes battery drain on Linux, Canonical updates kernel version policy |
| • Issue 1082 (2024-08-05): Linux Mint 22, taking snapshots of UFS on FreeBSD, openSUSE updates Tumbleweed and Aeon, Debian creates Tiny QA Tasks, Manjaro testing immutable images |
| • Issue 1081 (2024-07-29): SysLinuxOS 12.4, OpenBSD gain hardware acceleration, Slackware changes kernel naming, Mint publishes upgrade instructions |
| • Issue 1080 (2024-07-22): Running GNU/Linux on Android with Andronix, protecting network services, Solus dropping AppArmor and Snap, openSUSE Aeon Desktop gaining full disk encryption, SUSE asks openSUSE to change its branding |
| • Issue 1079 (2024-07-15): Ubuntu Core 24, hiding files on Linux, Fedora dropping X11 packages on Workstation, Red Hat phasing out GRUB, new OpenSSH vulnerability, FreeBSD speeds up release cycle, UBports testing new first-run wizard |
| • Issue 1078 (2024-07-08): Changing init software, server machines running desktop environments, OpenSSH vulnerability patched, Peppermint launches new edition, HardenedBSD updates ports |
| • Issue 1077 (2024-07-01): The Unity and Lomiri interfaces, different distros for different tasks, Ubuntu plans to run Wayland on NVIDIA cards, openSUSE updates Leap Micro, Debian releases refreshed media, UBports gaining contact synchronisation, FreeDOS celebrates its 30th anniversary |
| • Issue 1076 (2024-06-24): openSUSE 15.6, what makes Linux unique, SUSE Liberty Linux to support CentOS Linux 7, SLE receives 19 years of support, openSUSE testing Leap Micro edition |
| • Issue 1075 (2024-06-17): Redox OS, X11 and Wayland on the BSDs, AlmaLinux releases Pi build, Canonical announces RISC-V laptop with Ubuntu, key changes in systemd |
| • Issue 1074 (2024-06-10): Endless OS 6.0.0, distros with init diversity, Mint to filter unverified Flatpaks, Debian adds systemd-boot options, Redox adopts COSMIC desktop, OpenSSH gains new security features |
| • 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 |
| • 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 | 
Ubuntu Cinnamon
Ubuntu Cinnamon is an official flavour of the Ubuntu distribution featuring the Cinnamon desktop. The project strives to offer modern tools while providing a user-friendly desktop which will feel familiar for users coming from other operating systems, such as Microsoft Windows.
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.
|
|
• 
• 
• 
• 
• 
• 
• 
