 DistroWatch Weekly |
| DistroWatch Weekly, Issue 1080, 22 July 2024 |
Welcome to this year's 30th issue of DistroWatch Weekly!
Over the past few weeks we have been hearing multiple reports of vulnerabilities in the OpenSSH software which could grant remote attackers access or the ability to run code on unpatched machines. This week, in our Tips and Tricks column, we talk about some ways to shield vulnerable network services, such as OpenSSH, to thwart attacks. Do you run the OpenSSH secure shell service on any of your home computers? Let us know in this week's Opinion Poll. In our News section we talk about Solus dropping support for both AppArmor and Snap packages while openSUSE's Aeon Desktop edition gains full disk encryption. We also talk about SUSE making gains in the enterprise market while openSUSE contemplates rebranding at SUSE's request. First though we take a look at running GNU/Linux distributions on an Android phone. There are a few ways to approach running desktop and server Linux systems on a mobile device and this week we talk about one which is called Andronix. Read on to learn more about how Andronix works and both its benefits and limitations. Plus we are pleased to share an overview of last week's releases and share the torrents we are seeding. We wish you all a wonderful week and happy reading!
This week's DistroWatch Weekly is presented by TUXEDO Computers.
Content:
|
| Feature Story (By Jesse Smith) |
Andronix - Running Linux distributions on an Android phone
Over the years there have been a number of efforts made to get Android applications running on GNU/Linux distributions and also efforts made to get popular desktop Linux distributions running on Android devices. A few years ago I talked about an Android application, called UserLAnd, which helps the user install and run desktop Linux distributions inside containers on Android phones.
Unfortunately, it looks as though UserLAnd is no longer maintained and so, a few weeks ago, I went looking for a replacement which would allow me to run desktop Linux applications on my Murena smartphone. (Murena offers a de-Googled build of Android.) I found an project called Andronix which looked promising. Andronix is an Android application which is described on its website as follows:
- The Power of Linux on Android. Run full-fledged Linux Distros right on your Android device without rooting.
- Run distributions like Ubuntu, Manjaro, Kali and a lot more with all major desktop environments.
- Andronix uses PRoot to run your favorite Linux distribution on your Android devices.
The Andronix project goes on to mention it relies on an application called Termux, a terminal emulator for Android. Specifically Andronix relies on the version from the F-Droid repository, not the version from Google's Play store.
Getting started
I downloaded both applications, Termux and Andronix, on my smartphone and launched the latter. Andronix starts by showing us a welcome message with links to documentation. In my opinion, this is a great way to begin a user's experience with a new and complex utility. The Andronix application then gives us the opportunity to select a Linux distribution we want to install. The options are: Ubuntu, Debian, Manjaro, Kali Linux, Void, Fedora, Arch Linux, and Alpine Linux. Next to each distribution is a version number, indicating the newest version available. Most of the distributions listed are surprisingly out of date. The copy of Andronix I was running was released last year, but looking through the distributions available we see Ubuntu 22.04 is the latest available. The app only supports Debian 10 (four years old), Fedora 33 (four years old), an Arch snapshot from 2021 (three years old), and Alpine 3.10 (four years old). I'm not sure why most of the supported versions are so much older than the Andronix application, but it is overdue for a refresh.
Andronix -- The app's welcome screen
(full image size: 248kB, resolution: 1440x2960 pixels)
I decided to try Ubuntu first as it was the most up to date distribution in the list and it was presented at the top of the page with a "Recommended" label. (The Arch distribution is labelled as being in "Beta" status and I decided to skip it.) Once I had tapped the Ubuntu button, I was shown three interface options: Desktop, Window Manager, or CLI (command line). I decided to install a desktop. This brought me to a new screen where I was asked to pick from three options: Xfce (recommended), LXQt, or LXDE. I went with the suggested Xfce desktop. For those who are curious, the available window managers are: Awesome (recommended), Openbox, and i3.
Installing Ubuntu
Once we have made our selections for a distro and an interface, the Andronix app says it has copied the necessary command to acquire the software to our phone's clipboard. It then offers to launch the Termux app (the terminal emulator) for us. When we open Termux and paste the command Andronix has created, the command downloads some packages (such as wget and PRoot). Then a script is launched to fetch the appropriate distribution and another script is launched to set up the graphical interface. Assuming these steps are accomplished successfully, the new distribution is launched inside a container and a setup process is started.
Andronix -- Successfully running the Ubuntu container
(full image size: 218kB, resolution: 1440x2960 pixels)
Ubuntu's setup process uses a command line interface where we are asked to select our keyboard layout from a list. Then we are asked to pick our timezone. Then several more packages are downloaded via APT and installed. This process took several minutes on my modest phone. The setup took a little under ten minutes and, when it finished successfully, I was told that I could run a VNC session from inside the Ubuntu container on port 5901 by running the command vncserver-start. (Later, if we wish, we can stop the VNC service by running vncserver-stop. The container then automatically runs the VNC service and asks us to make up a password to protect it.
The user experience
At this point I was running a container with Ubuntu in it on my phone and I could access Ubuntu's desktop environment (Xfce in this case) over a VNC connection. It didn't matter if the VNC client was on my phone or on another computer, such as my laptop. As long as I had the password, I could access the Ubuntu desktop session on my smartphone. For example, if my phone was on the local network at IP address 192.168.2.14, I could open a VNC client on my laptop and connect to address:port 192.168.2.14:5901.
Andronix -- Accessing Ubuntu's Xfce desktop through VNC
(full image size: 208kB, resolution: 1488x839 pixels)
At some point, if we wish to stop using Ubuntu, we can exit the container. Later, we can re-launch the Ubuntu session by running the command ./start-ubuntu22.sh from inside a Termux session.
At this point I was able to open a terminal inside the Ubuntu session to run commands, I could install new applications inside the Ubuntu container using APT, and I could run desktop applications on the Ubuntu desktop when connected via a VNC session.
From the phone's host operating system I was able to browse the container's (Ubuntu's) filesystem. In the phone's file manager, I could select Termux as the location/device and then select the container's name ("ubuntu22-fs" in my case) to see the files in the container. This allows the host operating system to transfer files to and from the container without giving (as far as I can tell) the guest distribution direct access to the host's files.
Andronix -- Accessing the container's filesystem from the host phone
(full image size: 105kB, resolution: 1440x2960 pixels)
There are some limitations inside the container. For example, there is no /proc filesystem mounted and this prevents some programs from working. Utilities such as uname and cpulimit will not work in the container environment.
Removing old distributions
At first I could not find an obvious method for cleanly removing an existing distribution container. The Andronix app doesn't have a button that looks like a trash or removal option and there isn't any script saved in the Termux environment which indicates it is intended to remove old containers. I eventually found instructions for removing containers under the Installation part of the Andronix documentation
To remove a container we basically go through the same initial steps in the Andronix app we would use to create a container, but then tap and hold on the distribution we wish to remove. In my case pressing and holding the Ubuntu button gave me an option to remove the container. Or, more specifically, selecting the Remove option copied a command to my phone's clipboard I could paste into Termux to delete the container. This worked and the clean-up process took only a few seconds.
Trying other distro/desktop combinations
I decided to try some of the other distribution and desktop options Andronix provides. In particular, I wanted to see if I could install Void since it's a rolling release and I wouldn't need to worry about performing a major upgrade later. The Void base installs, but the selected Xfce desktop was not installed. In fact, apart from a minimal framework, no Void packages were installed. A little investigation showed that Andronix's base install of Void was too old and its repository certificate was out of date. This prevented the system from downloading the necessary packages from Void's repository. I was sorry to note that the Void uninstall script also failed to work and I had to remove the Void container manually inside the Termux terminal.
I also tried installing Ubuntu 22.04 again with different desktop environments. These attempts were without success too, with the install processes failing each time while trying to find and download the desktop's icon theme package. I'm not sure if this is a mistake in the Andronix setup process or an error with the distribution's package repository. No error message is displayed, the setup process simply hangs and never recovers.
Eventually, I went back to re-installing Ubuntu with Xfce as the other desktop options didn't work for me.
Practical and silly tasks
I tried performing a few tasks with Andronix's containers. Some of these were practical and some were silly. As an example of a silly task, I sat down at my laptop. From the laptop I used VNC to connect to my Murena phone running the Ubuntu container. From Ubuntu's Xfce desktop, I used an OpenSSH session to remote into a PinePhone running UBports I had in another room. I then started playing Tetris on the UBports phone. Stringing these technologies together and having it work fast enough to play a game involving reflexes was impressive, but not at all practical.
Andronix -- Running Tint on a PinePhone, accessing it from the Ubuntu container, through VNC from a laptop
(full image size: 178kB, resolution: 1488x839 pixels)
So what is a more practical application of Andronix's container technology? There are a few things we can use it for, such as testing ARM builds of desktop Linux software. We can also start processes in the container and then leave them running in the background as we go about our day. This means, for instance, I could start a task at home, take my phone to work, and finish the task there - all while running the same operating system on the same device. This might be more convenient than starting a task on my workstation at home and then remoting in from work to see if it has completed.
Conclusions
I like Andronix and how easy it is to use. Combining Andronix and Termux means we can usually just paste commands into Termux to setup or remove a container. The setup process is mostly automated and it's easy to connect to a container using VNC.
The downside I experienced was that most distributions offered by Andronix were years out of date. This means some distributions either don't install, don't work properly, or no longer receive updates. This is a problem which is only going to get worse with time if Andronix isn't updated. I hope the existed distributions are refreshed or some options are removed to make it more clear which projects are supported, tested, and known to work.
|
| Miscellaneous News (by Jesse Smith) |
Solus dropping AppArmor and Snap support, openSUSE's Aeon Desktop gaining full disk encryption, SUSE gaining ground in the enterprise market while asking openSUSE to rebrand
The Solus developers have announced a plan to reduce the project's maintenance burden by phasing out AppArmor support in the kernel and, eventually, dropping support for Snap packages. "With the 6.9 update to our Current branch of the Linux kernel, we are dropping the AppArmor patchset from Canonical. This means that Snaps will now run with partial confinement if you are using the current kernel. Our LTS kernel will still have the AppArmor patches applied. Dropping these patches is the first step in ending support for Snap on Solus. Snaps will still be supported for the rest of 2024, they will just be running with only partial confinement. Long-term, Snap users are encouraged to explore alternative solutions, such as Flatpak." Additional information, along with migration plans for people currently using Snap, can be found in the distribution's blog post.
* * * * *
The openSUSE team have announced the immutable, Aeon Desktop edition of the distribution will soon offer full disk encryption. "Full disk encryption is planned to be introduced in the forthcoming release candidate of the Aeon Desktop to enhance data security for its users. The feature is expected to be included in the upcoming Release Candidate 3 (RC3). Full disk encryption is designed to protect data in cases of device loss, theft or unauthorized booting into an alternative operating system. Depending on the hardware configuration of a system, Aeon's encryption will be set up in one of two modes: Default or Fallback. The Default Mode is the preferred method of encryption provided the system has the required hardware. This mode utilizes the Trusted Platform Module(TPM) 2.0 chipset with PolicyAuthorizeNV support (TPM 2.0 version 1.38 or newer). In this mode, Aeon Desktop measures several aspects of the system's integrity." Details can be found in the project's announcement.
* * * * *
FOSS Force recently ran an article which suggested SUSE is starting to replace Red Hat as the standard bearer for enterprise Linux. In part this is due to Red Hat's mishandling of CentOS and SUSE's willingness to not only support its own products for longer periods of time, but to also support Red Hat's former products past their normal end of life dates. This gives SUSE an air of stability and predictability. However, at the same time, not everything is running smoothly in the SUSE and openSUSE communities. SUSE has apparently asked openSUSE to change its name (again) and there are concerns openSUSE doesn't currently have the governance in place to effectively manage its own project. The issues are being discussed in a mailing list thread. "Let me first define a couple of things that the community is being faced with: Our current governance is not working. With the things we're facing and the current model / Board rules, there is no good way the Board could drive the resulting changes coming up. Bi-weekly meetings will definitely not be enough. Furthermore, the Board has not shown any real proactive leadership in some situations where it should have. In the end, the reason I stepped down from it.
Whether we like it or not, we have to rebrand the project. We can start working on it now and be proactive, or later be forced by [eg.] some new owner of SUSE (mind, SUSE has expressed their concern about such a thing happening and clearly stated that they do not want to get rid of the project). To drive this we need something else than the Board as it is now. But keeping things as they are simply is an unrealistic option."
* * * * *
These and other news stories can be found on our Headlines page.
|
| Tips and Tricks (by Jesse Smith) |
Port knocking and other ways to protect OpenSSH
A few weeks ago we reported on a vulnerability in OpenSSH which could, in theory, allow an attacker to remotely run code on the computer running the OpenSSH service. I say "in theory" because, even in lab conditions, it took several hours for researchers to trigger the exploit on 32-bit machines. It might be possible to also successfully exploit 64-bit machines, but it would likely take longer, maybe days of attacking the service, to successfully exploit the flaw.
Still, any vulnerability which grants remote access to our computers is something to be taken seriously and Linux distributions around the world quickly issued patches to protect against this possible assault. The following week another issue was discovered in OpenSSH packages used by the Fedora/Red Hat family. It hasn't been a fun month to be an administrator running the OpenSSH service.
In the wake of the news that OpenSSH could be exploited, we received some follow-up questions and suggestions. In particular, we were asked if we could talk about ways to protect services like OpenSSH from being exploited in situations where a fix is not yet available. Can a firewall be used, what about a technique called "port knocking", and what other options are available to people wishing to hide their vulnerable network services?
I'd like to point out that what I'm planning to talk about here is not how to protect user accounts from someone logging in remotely by guessing username and password combinations. There are plenty of guides out there which talk about disabling password authentication and using generated security keys for authentication instead. There are also other guides which will talk about allowing only specific users and groups to sign in, and disabling root logins. There are some helpful tools which will block login attempts after a series of failed tries and fail2ban is well worth looking at to protect your OpenSSH configuration. I highly recommend looking at each of these options as they can make it much harder for casual attackers to break into your system remotely using commonly guessed username and password combinations.
What most of the above options have in common is they rely on OpenSSH itself to be in good working order and for the rules in its configuration file to be obeyed. What I am going to be discussing today are techniques for protecting OpenSSH itself when attackers may know of a vulnerability they can use to try to bypass OpenSSH's rules - and its normally excellent security.
Alternative ports
One of the easiest, and perhaps most common way, to "hide" network services like OpenSSH is to run them on alternative ports. Network services all have a default port where they wait for incoming connections. Web servers mostly listen on ports 80 and 443, e-mail servers mostly listen on port 25, and OpenSSH uses port 22. While these are the defaults, the place where connecting clients will check for a response, nothing prevents us from using another port number.
Switching from the default port to another has one minor drawback: it means we need to tell any client program we use to connect on the alternative port. This usually isn't a big deal if you're the system administrator or your machine is accessed by just a few people. However, if you have many users, or less technically experienced users, getting everyone to setup their client to connect on an alternative port can be cumbersome.
The benefit to this approach is that most malicious traffic, bots trying to guess passwords and malware trying to break in, will quickly scan the Internet looking for responses on default ports only. Switching from using OpenSSH's default port 22 to a high numbered port, like 10022, will likely reduce the amount of casual, drive-by break-in attempts by around 90%.
A word of warning: moving to another port stops only the casual, drive-by style attacks. It's a low-effort defence against low-effort attackers. Anyone interested in your machine specifically or any bots with more sophistication, will scan the machine for open ports and notice the alternative port in use. This defence requires no extra software, only one configuration line change, but the downside is it also offers just the thinnest of armour against attackers.
Port knocking
A more complex and interesting defence for network services is called port knocking. The basic idea behind port knocking is we set up our firewall to block all incoming traffic, allowing nothing through. However, we also run a service which listens to connection attempts on specific, closed network ports. When the service (called a knock daemon) hears connection attempts coming into specific ports in a specific order then it opens up the firewall to allow us to connect to our service.
Typically, the knock daemon can also listen for a second sequence of connection attempts which instruct it to close the firewall again, blocking connections to our network service.
The main perk of this approach is the process of port knocking acts like an extra password or secret handshake the attacker must know (or guess) before they can access our network service. At a glance, our server seems to be running no services and its firewall is blocking everything. The attacker either needs to figure out the "knock" sequence or try to attack our server at the same time a legitimate user has used the knock technique to open the firewall in order to gain access. This can greatly reduce casual attacks.
There are a few drawbacks to using the port knocking approach. The first is the complexity involved. (Even the always excellent Arch wiki's guide for a simple port knocking tutorial is over a page long.) To set up port knocking we need to configure the firewall, install and set up a port knocking daemon on the server. Then, on any client machine which we want to connect to our server, we need to set up a script that will send the "open" knock sequence and a following "close" knock sequence to hide the services after each use. This also means everyone who uses the server must remember to send the "close" knock sequence after they are finished accessing the server.
In short, this approach really only works on systems where we have a small number of people accessing the server and, ideally, for short periods of time. High traffic servers or servers with multiple users won't benefit much from port knocking. It's a relatively large amount of work for medium results.
Firewall throttling
An approach which is easier to set up than port knocking is port throttling. Almost all firewall tools on Linux and the BSDs offer some form of easy to set up port throttling. What this does is allow us to limit the number of connection attempts a remote computer can make to our server in a period of time. For instance, we might allow a remote computer to only attempt to connect to one of our services 6 times within 30 seconds.
Limiting the number of incoming connections from a remote computer usually has no negative effect on legitimate traffic while making brute force attacks, denial of service attacks, and complex attacks (like the one we recently saw against OpenSSH) virtually impossible.
Each firewall utility has its own rule syntax and I won't list all the possible examples here. I will share one example of throttling the OpenSSH service using the UFW tool, just because UFW makes this process so wonderfully simple. The following command throttles traffic to the OpenSSH service on any system making use of UFW:
ufw limit ssh/tcp
The above command line is the entire setup. As I said, the configuration is quite simple, the effect prevents most types of attacks, and it has minimal (if any) impact on legitimate users. The only real drawback I've run into is throttling traffic will not help us in situations where a service has a known vulnerability that can be quickly exploited, using just one or two connection attempts.
VPN/Proxy
A fourth popular approach to hiding sensitive network services is to place them inside a virtual private network, or behind some other form of proxy. The idea here is the user needs to access the virtual private network (VPN) in order to be able to connect to our network service; the service isn't visible to the public Internet.
There are several different approaches to setting up this sort of situation and I won't dive into them here. The benefits and drawbacks are similar to port knocking, at first glance. Setting up a VPN which users must connect to in order to reach the service requires additional infrastructure (usually an extra server providing the VPN), the users all need to know how to access and use the VPN, and they need to remember an extra set of credentials. It's a bit of a complex solution and not at all seamless, especially with multiple users. On the positive side, a server hiding behind the VPN should be immune from all attacks, assuming the VPN itself isn't compromised first.
This approach is probably more effort to set up than it will be worth for people running services at home, it's more geared toward businesses. However, it is one option people can try.
Combinations of the above
Security is largely about implementing layers of protection. Any one security feature can be exploited or bruteforced, given enough time. However, placing multiple layers of protection between your service and the public Internet greatly improves your security. Most attackers on the Internet are seeking out and taking advantage of "low hanging fruit", the easy targets.
Most attacks against OpenSSH are not complex, the attacker will guess a few dozen commonly used default username and password combinations and then move on to the next server. This means putting just a few hurdles in place can have a big effect in reducing malicious network traffic and denying automated attacks.
Even fairly simple measures, such as moving OpenSSH to an alternative port (a single-line configuration change) and limiting the number of allowed incoming connections on the alternative port (also a single-line command with UFW) will filter out the vast majority of break-in attempts. Further locking down the system using either complex passwords or enforcing security key logins will deny almost all attackers. Remember, to avoid being successfully attacked on the Internet we don't need our security to be perfect, usually we just need it to be better than the "low hanging fruit" - the machines without firewalls, the devices still using their default login credentials, and the servers which allow endless connection attempts.
* * * * *
Additional queries and answers can be found in our Questions and Answers archive.
|
| Released Last Week |
NomadBSD 141R
NomadBSD is a live desktop system for USB flash drives, based on FreeBSD. The project has published a new update, NomadBSD 141R, which brings the base system up to date with FreeBSD 14.1. The release announcement shares the highlights: "Changes since 140R-20240126: The base system has been changed to FreeBSD 14.1-RELEASE-p2. A hard link creation bug concerning unionfs has been fixed. A calculation bug which led to an overfull UFS root partition has been fixed. The fusefs module has been changed to reduce (and hopefully eliminate) timeout errors on unionfs. The NomadBSD tools have been ported from Qt5 to Qt6. Several small improvements and bugfixes." NomadBSD is available in UFS and ZFS flavours for multiple architectures.
RELIANOID 7.3
The RELIANOID project develops a Debian-based load balancing platform. The project's latest release, version 7.3, is based on Debian 12.6 and introduces a number of fixes and improvements. The project's release notes read: "Improvements: Update to Debian 12.6. Angular libraries and components update. Translation improvements. Refactoring API to avoid source code duplication. Switch services to systemd. Advanced best QA practices applied. Seamless upgrade from CEv7 to EEv8. Improve memory usage downloading large backups. Bug fixes: Network stats not shown in the dashboard. Fix show real memory usage. The update to Debian 12.6 includes the latest security patches and critical fixes, providing a solid and secure foundation for the load balancer. Users will also benefit from an upgraded GUI, featuring the latest Angular libraries and components, which enhance the user interface's responsiveness and modernity. Additionally, translation improvements have been made to better support our international user base."
Nobara Project 40
Nobara Project is a modified version of Fedora Linux with user-friendly fixes added to it. The distribution's latest release, version 40, includes KDE Plasma 6.1.1, GNOME 45, and several updates to package management. "The 'Update System' App has been completely remade into a Python GUI application. No more monolithic bash script. The 'Update System' App has been better integrated with Nobara Package manager (yumex-ng) and now provides a service which runs as a system tray app for receiving update notifications. The system tray app is fully configurable within Nobara Package Manager's settings and includes options to hide the icon completely or change it's update check interval timer. Nobara Package Manager can now fully search, install, and remove Flatpaks in a user-friendly way on the GUI, obsoleting the need for kde-discover or gnome-software. The PackageKit plugin for KDE discover has been removed so that it does not manage system packages. KDE Discover does not come with the Nobara Official release, however it is still provided on the KDE release. If users intend to used KDE Discover we want them to use it for Flatpaks only. The same goes for gnome software. It is still provided although it is not needed, and our intention is for users to use it for Flatpaks only. Again, we want system packages to be solely managed by Nobara's Update System app and the Nobara Package Manager. We have spent a lot of time and effort building quirk fixes and checks into our package manager that others normally would not be able to help with. Snaps should be better supported now. Issues have been fixed which prevented lxd and various other apps from operating in the past. We have now introduced Nobara Driver Manager thanks to the help from Cosmo and our friends over at PikaOS. It is limited in what it currently provides but we plan to grow it in the future for hardware that needs third-party driver support." Additional information is provided in the release announcement.
Nobara Project 40 -- Running the GNOME desktop
(full image size: 1.3MB, resolution: 1680x1050 pixels)
OpenMandriva 24.07 "ROME"
The OpenMandriva project has released a new snapshot of the project's rolling "ROME" branch. The new snapshot, version 24.07, migrates the Plasma desktop to version 6 and updates LXQt to version 2.0.0. "Switch to the KDE Plasma 6 desktop by default. Spins featuring LXQt (2.0.0 Qt6) and GNOME (46.3). Also provided is a ROME Plasma6 Wayland ISO, however we believe Wayland still not to be mature enough to replace X11 by default for most users. Please note the Wayland ISO in VirtualBox almost always will boot to a black screen and will not work. It works fine on most hardware and in QEMU with KVM. In addition to the normal wine Windows emulator, proton and proton-experimental - variants of wine that are typically used to run Windows games inside Steam - are now available as OpenMandriva packages. For the first time, this makes Proton available outside of Steam, without the need to install any non-free code. OM-Welcome, the new Startup and Configuration tool for OpenMandriva Lx is now a merge of modules from the historical brand-name applications oma-welcome and om-control-center features. It aims to be a convenient centralized all-in-one starting point both to configure the system and to install software." Additional information can be found in the project's release announcement and in the release notes.
OpenMandriva 24.07 "ROME -- Running the KDE Plasma 6 desktop
(full image size: 788kB, resolution: 1920x1440 pixels)
* * * * *
Development, unannounced and minor bug-fix releases
|
| Torrent Corner |
Weekly Torrents
The table below provides a list of torrents DistroWatch is currently seeding. If you do not have a bittorrent client capable of handling the linked files, we suggest installing either the Transmission or KTorrent bittorrent clients.
Archives of our previously seeded torrents may be found in our Torrent Archive. We also maintain a Torrents RSS feed for people who wish to have open source torrents delivered to them. To share your own open source torrents of Linux and BSD projects, please visit our Upload Torrents page.
Torrent Corner statistics:
- Total torrents seeded: 3,038
- Total data uploaded: 45.0TB
|
| Upcoming Releases and Announcements |
|
Summary of expected upcoming releases
|
| Opinion Poll (by Jesse Smith) |
Running the OpenSSH service
There has been a lot of talk in recent weeks about the OpenSSH secure shell service. OpenSSH is widely used across multiple platforms as a way to remotely access computers and transfer files. This week we'd like to know if you run OpenSSH or another secure shell implementation.
You can see the results of our previous poll on favourite immutable distributions in our previous edition. All previous poll results can be found in our poll archives.
|
Do you run a secure shell service at home?
| Yes - using OpenSSH: | 581 (29%) |
| Yes - using another secure shell daemon: | 22 (1%) |
| No: | 1411 (70%) |
|
|
| Website News |
DistroWatch database summary
* * * * *
This concludes this week's issue of DistroWatch Weekly. The next instalment will be published on Monday, 29 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 | 
Feather Linux
Feather Linux was a Linux distribution which runs completely off a CD or a USB pendrive and takes up under 128MB of space. It was a Knoppix remaster (based on Debian), and tries to include software which most people would use every day on their desktop.
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.
|
|
• 
• 
• 
• 
• 
• 
• 
