 DistroWatch Weekly |
| DistroWatch Weekly, Issue 909, 22 March 2021 |
Welcome to this year's 12th issue of DistroWatch Weekly!
Many of us are on-line virtually every minute of the day. We live in an increasingly connected and a highly mobile world. Many of us watch videos on-line, send e-mails through always-on webmail, share documents through cloud services, and store backups on remote servers. With all of this in mind, it makes sense to examine the extra mobility afforded by using an always-on, virtual workstation too. This week we begin with a look at Shells, a service which runs workstation operating systems on remote servers, providing around the clock desktop environments to any Internet-connected device. Read on to learn how Shells performs and why it might be useful to you. Do you run a desktop environment on a cloud service? Let us know about it in our Opinion Poll. In our News section we talk about new features coming to Fedora 34 while the FreeBSD team re-implements their WireGuard code. Plus we share new developments and improvements coming to the UBports mobile distribution. In our Questions and Answers column we explore weird or unusual tasks which can be performed with Linux. What is the oddest task you have completed using Linux? Be sure to share it in the comments. We are pleased to share the releases of this past week and list the torrents we are seeding. We are also happy to welcome two new distributions, JingOS and Regata OS to our database. Details on both of these projects can be found below. We wish you all a fabulous week and happy reading!
Content:
- Review: Running an always-on desktop with Shells
- News: New features planned for Fedora 34, FreeBSD gets new implementation of WireGuard, UBports discusses project's progress
- Questions and answers: Strange, unusual, and fun things to do with Linux
- Released last week: UBports 16.04 OTA-16, Linux Kodachi 8.0
- Torrent corner: Absolute Linux, kDE neon, Kodachi Linux
- Upcoming releases: Fedora 34 Beta, Tails 4.17
- Opinion poll: Always-on remote desktop machines
- New additions: JingOS, Regata OS
- New distributions: Peropesis, DarkOS
- Reader comments
Listen to the Podcast edition of this week's DistroWatch Weekly in OGG (15MB) and MP3 (11MB) formats.
|
| Feature Story (by Jesse Smith) |
Running an always-on desktop with Shells
Shells is a service which provides an Internet-based virtual machine running a pre-configured desktop environment. The Shells website describes its service as follows: "Shells are Intel powered cloud computers that are always on, just like a desktop computer." A virtual machine (or "shell") is accessed through a web browser, such as Firefox or Chrome. "Shells provides you with a 1-click, powerful virtual desktop environment, driven by a cloud computer, without leaving your browser!"
The idea is we sign into the Shells.com website, select which operating system we want to run and the system logs us in, running the remote desktop session in our web browser. We can run desktop software on the remote machine, work on documents, and listen to music, all through our web browser. We can then login to the same remote machine from another location or device, using any Internet connected smart phone, tablet, Xbox, PlayStation, or laptop.
This basically gives us a virtual private server (VPS) with a pre-configured desktop environment we can sign into at any time from any location with an Internet connection. Once signed in we have a full featured Linux distribution where we can run desktop applications, install software, access the command line, and set up services.
Plans and pricing
The Shells website currently lists four available remote desktop machine plans. The introductory plan offers 100 hours on a single core CPU with 40GB of storage space and 2GB of memory. This plan is just $4.95 per month. The highest end plan offers unlimited usage with 4 CPUs, 160GB of disk space, and 8GB of memory for $36.95 per month. There are two intermediate plans between these far ends of the spectrum. In my experience this puts Shells on approximately even price footing with virtual private servers (VPS) with similar specifications from other companies.
The Shells team was nice enough to give me a free month of one of their higher end plans to play around with and see what the experience would be like.
Supported operating systems and desktops
There are currently a number of pre-selected distributions and desktop environments available. It looks like Shells has stuck to some of the more popular Linux distributions for their offering. Looking through the list of available distributions I found Ubuntu, Ubuntu Server, Kubuntu, Lubuntu, Xubuntu, and KDE neon. There are two editions of Manjaro (KDE and Xfce), two editions of Debian (Debian GNOME and "Debian with Desktop"), and two editions of Fedora (Workstation and "Custom"). There is also an image of Windows 10 available, though it is unregistered. I haven't discovered what "Fedora Custom" and "Debian with Desktop" are yet.
Shells -- Creating a new shell
(full image size: 110kB, resolution: 1237x1024 pixels)
I had wondered about uploading or requesting custom distributions. The Shells team was open to the suggestion, but at this early stage they are focused on curating their own selection of popular distributions. I opted to try out the Manjaro Xfce edition.
Within a minute my new virtual machine (shell) was set up and a confirmation e-mail with my initial password had been sent to me.
First impressions
When I first got signed into the Shells dashboard and tried to launch my new Manjaro machine I was running the Falkon web browser. Trying to connect to my new shell failed with an error which was not all that surprising since Falkon isn't one of Shell's supported browsers. They do support Chrome, Firefox, and Safari. I switched to Firefox and enjoyed a smooth experience from then on.
Clicking the View button in the Shells dashboard opens a new browser tab and displays the Manjaro login screen. Accessing a shell is a lot like running VNC or a remote desktop tool and connecting to another person's computer, just from within the Firefox browser.
Shells -- The Shells dashboard
(full image size: 108kB, resolution: 1237x1024 pixels)
I ran into a little problem here when I tried to sign into my account. The password I had been e-mailed was not working and I was unable to sign in using it, even when copy/pasting the password. I went back to the Shells dashboard and found a set of options which allow the user to re-install their remote operating system and create a new default password. This works and, perhaps more importantly, Shells sent out a verification code to my e-mail address before completing the re-install to insure I did not accidentally experience any data loss.
Installing the new operating system (Manjaro Xfce again) with my new password took less than two minutes, making it a very fast set up process. It occurs to me that this would make it easy to try out a lot of new versions of Linux distributions quickly as Shells completely removes the installation and configuration time usually required to set up a new operating system locally.
Shells -- Re-installing the operating system with several choices
(full image size: 125kB, resolution: 1237x1024 pixels)
Observations and performance
The first thing I feel it is worth mentioning is that running a shell on the Shells service feels a lot like running a Linux distribution in a local copy of VirtualBox. In both cases we are running an operating system in its own application window. In both cases there can be a little lag, but otherwise the experience is very similar to running the operating system natively. One perk of using Shells is that any tasks we run on the remote server do not consume local resources on our computer. This means we can have one or more shells running, crunching numbers or compiling code, and it won't have an impact on the local machine's performance.
The remote shell's desktop tries to resize to fit the local web browser. Usually this works okay, but sometimes I had to logout of the remote system and log back in again for it to handle switching to full screen resolution. When I accessed the Shells service on my phone, rotating the phone between portrait and landscape mode did not result in the remote desktop resizing, which left it in an awkward resolution. This is a minor consideration in most situations, but something to keep in mind if you plan to run the remote shell in a full screen browser window. It's a good idea to set your web browser to full screen up front rather than resizing it after you sign in to the remote shell.
The shell I was using mostly worked smoothly and fairly quickly, considering the remote data centre was in another country. Xfce responded slower than it would when run natively, obviously, but shells out performed 3-D desktops (such as GNOME and Cinnamon) running in VirtualBox on my local workstation.
Shells -- Running Manjaro's software centre on Xfce
(full image size: 344kB, resolution: 1237x1024 pixels)
The network speeds I enjoyed while running my remote shell were good. I regularly got download speeds from package mirrors in the range of 3MB/s to 5MB/s. Network speed tests put the upper limit of the shell's bandwidth at about 50MB/s, both for uploading and downloading data.
A limitation I ran into was that I could not Alt+TAB between windows in the web browser. This key combination would shift me to a different local window rather than change windows in the shell. This was to be expected and it meant I had to do most of my window management in the remote shell using my mouse pointer.
New shells are set up to provide the user with a regular (non-root) user account. However, the sudo command can be used to provide administrator access without a password. This is done by giving all members of the wheel group no-password admin access through sudo and making the default user a member of the wheel group. We can adjust this behaviour once the shell has been created, if we wish.
One feature I was especially pleased to read about was automated backups. Every day Shells takes a snapshot of the remote machine. Each snapshot is kept for a week. We can browse snapshots that have been taken and then click a Restore button next to a snapshot to revert our shell to its previous state. I thought this would be useful in at least three situations: when testing out new software which we might want to install, then remove from the operating system entirely; when testing new procedures which might be destructive, requiring the system to be rolled back; or when accidentally deleting or corrupting important files.
After a few days of using Shells, I deleted a directory full of files, then shut down the remote shell. I went into the dashboard and selected the previous day's snapshot. When I clicked Restore a warning appeared, letting me know this would wipe out all changes since the snapshot had been made. I chose to proceed and, during the restore process, an error appeared reporting simply "bad method". My snapshot was not restored and, when I booted into the remote shell, I discovered my deleted files were still missing and the shell was unchanged. The restore had failed. I tried this again with another snapshot and it again failed. Apparently the snapshot and restore function is not working yet.
While looking for project ideas to make use of the Shells service I found mention on the organization's website and Twitter feed that suggested Shells could be used as a media service. Basically if we upload media files to a shell we can leave a media player open and then connect to it from any device with a web browser to have an instant media player with a large collection of songs and videos. I will come back to the process of sharing files to and from a shell later.
I did upload some music to my shell and installed the Rhythmbox audio player. When I tried to play music files the remote shell indicated sound was playing, both in Rhythmbox and in the audio mixer, but no sound was coming to my local web browser. I spent about five minutes trying various tweaks and checking settings on both my local machine and in the remote shell. Then I closed Rhythmbox and moved on to trying other things. A few minutes later my speakers blared out a single line of the song I had been trying to play and then fell silent again. I relaunched Rhythmbox and, this time, with no adjustments on my part, the audio files played. I'm not sure why there was such a long delay the first time, but future attempts to play music always worked immediately.
The quality of audio varied. When I was accessing my shell from my workstation running Firefox audio would lag and stutter. When I accessed the same shell from my phone, also running Firefox on the same network as my workstation, audio played smoothly.
Shells -- Testing responsiveness when typing
(full image size: 411kB, resolution: 1237x1024 pixels)
Sharing files and alternative access
Earlier I mentioned uploading files to the remote shell. Unfortunately Shells doesn't yet provide a method for seamlessly transferring files between the local computer and the shell, or between separate shells. However, the service does provide an open port which gets forwarded to the shell's network port 22. The port and IP information can be found through the Shells dashboard. This means we can use OpenSSH to upload or download files through the public-facing IP address and port. The only catch is OpenSSH needs to be enabled on the remote shell. With Manjaro that means installing the OpenSSH package and enabling the sshd service.
The Shells representative I communicated with mentioned that, in the future, it may be possible to transfer files between computers using drag-and-drop on the local desktop and possibly access local USB drives.
When I brought up the issue with audio lag between the shell and my workstation it was suggested I try out the Shells native application. This tool is supposed to provide a slicker interface to connecting with shells than a web browser and, I presume, with less overhead. There are native applications for desktop machines and mobile devices. I downloaded the Linux desktop client, which is a compressed 8MB download. This compressed archive expands to 16MB. The archive holds a single executable file which failed to run on my Debian 10 test machine. A little investigation revealed the Shells client requires newer versions of the glibc and xcb libraries than are available for Debian's Stable branch. I suspect this will also be a problem for other long-term support distributions, meaning the Shells client will probably only work on fairly modern or rolling release versions of desktop Linux.
After writing the bulk of this review, the Shells team let me know there was a new version of the client they were testing which would be compatible with older system libraries. I gave the development snapshot a test run. The client is fairly simple and starts off by showing a login screen and then showing us a list of our active shells. We can click on a shell to connect. The good news, I found, was the Shells desktop client does feel faster and more responsive than accessing the remote machine in a web browser. However, there were two drawbacks. One is there was no sound - audio applications did not send sound to my local machine. The second issue was there were a lot of visual artifacts which cluttered parts of the display and turned menus unusual colours, making them hard to read at times.
Shells -- Running the native Linux desktop client
(full image size: 424kB, resolution: 1326x768 pixels)
Overall impressions
As with any new service or technology, I spent a little time playing around with Shells, figuring out what it was good at and what wasn't going to be useful for me. My overall view on Shells is that it provides a method for very quickly setting up remote virtual machines that are pre-configured with desktop environments. We can then easily access the virtual machines through a web browser on virtually any Internet-enabled device.
The performance of the remote machines is good, they have a decent-to-good range of resources, depending which plan we use. This gives us the opportunity to test new distributions and desktops, try out new programs in an isolated environment, and have access to an "always-on" Linux desktop from almost anywhere in the world.
As with other remote virtual machine services, there are limitations. Transferring files between the shell and a local machine takes some command line knowledge and may involve installing OpenSSH. At this point there doesn't seem to be any way to automatically bundle together shells to share resources or a virtual private network. While the performance of the virtual machines is good, sometimes I experienced lag. I could happily work with LibreOffice, write code, or update a calendar application through Shells, but I wouldn't try to do more latency-sensitive activities such as watching a movie or edit an audio clip.
Shells appears to have three main qualities working in its favour. It allows us to run computations that might require more memory or CPU than our local machine has. We can spin up a remote shell, let it run for days or weeks, and not worry about the impact to the local computer or our local machine's resource limitations. Second, the remote shell can always be on. We don't need to worry about putting it to sleep or fan noise in the middle of the night. We don't need to worry about missing a notification or interrupting a task as we would if we needed to pack up a laptop and transfer it to another location.
Finally, setting up a new shell or destroying an old one happens very quickly. We can deploy new operating systems, test them, or build code on them in a few minutes. This is much faster than installing a new operating system locally on bare metal or in a virtual machine. This makes Shells appealing for testing software.
The downside to Shells is that it feels like new technology where some functionality which would be really useful (such as drag-and-drop file transfer) is missing and some functionality doesn't work yet. The most notable issue I ran into was with backups not restoring and not giving a useful error message when they failed. There is also a little bit of lag which means certain tasks that require a responsive interface won't work properly. However, my shell was responsive enough for most basic tasks.
Why Shells and not a VM or laptop?
I mentioned to a few people that I was testing out a Shells account and, having explained the concept to them, the initial reaction I got was usually to question what Shells would offer that I wouldn't get from a local virtual machine or a laptop that I could carry around to different locations. To be fair, one or both of these options could cover a lot of the functionality Shells provides, however, Shells sometimes does a better job than one or the other, or offers conveniences the others do not.
For instance, setting up a new operating system in Shells is faster than doing it locally, either on bare metal or in a virtual machine. There is no need to do the initial configuration and the new operating system is ready within two minutes.
Though the snapshot feature did not work for me during my trial, once the bugs are sorted out, the daily snapshot backups are going to be a great selling point. I can take regular snapshots of a local virtual machine, and I can set up filesystem snapshots or rsync backup jobs on my laptop. However, having this done automatically and having snapshots restored with two clicks is a very appealing arrangement.
Running a remote shell does not take up any drive space. This makes it an attractive option for testing distributions, desktops, or other software. We can spin up a remote shell without consuming local drive space. This is especially handy if our local computer has a small SSD or we want to run multiple distributions, each one taking up 20-30GB of storage.
On a similar note, we can run as many shells as we like without impacting the local computer's CPU or memory usage. One of the limits I run into when running local virtual machines is they all require at least a gigabyte of RAM to function smoothly and performing intensive tasks in any one virtual machine can slow down the host system. With Shells I can set up a few tasks and let them run all day without impacting my workstation's performance.
With a Shells account we don't need to take a valuable computer into unpleasant situations. I've talked with a few people who work in areas where laptops might either be searched or stolen. Others work in environments where they can't take work equipment home or home equipment to work. This means they need to transfer files another way, such as via USB thumb drives or cloud storage. Using a tool like Shells they wouldn't need to share files between multiple computers and services, everything can run in the remote shell. In a similar vein, I don't always want to suspend my laptop in the middle of a task, such as downloading ISO files. Transferring work to a Shells account means I can pack up my laptop on a whim without interrupting running tasks.
There are limitations to Shells, such as requiring a quick, stable Internet connection to access it. Performance may not be as snappy as with a local machine, and transferring files requires knowing how to send or receive files using a tool like cloud storage or OpenSSH.
I can certainly see the benefit to having Shells, especially if we travel a lot and always want to have access to the same, always-on desktop system. I also think it provides an interesting method for testing code or applications across multiple distributions without requiring any local management or the consumption of local computing resources.
|
| Miscellaneous News (by Jesse Smith) |
New features planned for Fedora 34, FreeBSD gets new implementation of WireGuard, UBports discusses project's progress
Fedora 34 is expected to be released soon and there are a number of new features planned. One of them is accelerated graphics in XWayland sessions, even on equipment running NVIDIA drivers, which have historically not always worked well with Wayland. Another is PipeWire: "PipeWire as most of you know is the engine we use to deal with handling video streams in a secure and shareable away in Fedora Workstation, so when you interact with your web camera(s) or do screen casting or make screenshots it is all routed and handled by PipeWire. But in Fedora Workstation 34 we are aiming to also switch to using PipeWire for audio, to replace both PulseAudio and Jack." Details on these changes as well as progress being made with Toolbox and Flatpak can be found in this blog post.
* * * * *
Back in December 2020 we reported that WireGuard was being implemented for the FreeBSD operating system. Since then members of the FreeBSD team have looked over the committed code and found issues with it, taken a new approach, and greatly simplified the code: Jason Donenfeld commented: "I'm pleased to announce that WireGuard now runs inside the FreeBSD kernel, with a driver called if_wg. It has full support of wg(8) and wg-quick(8), as well as general integration into FreeBSD userland. Performance should be decent. The implementation in FreeBSD's main branch should pretty much work, though it's something of a so-so work in progress." Background on WireGuard development in FreeBSD along with issues the team has fixed are discussed in this mailing list post.
Following this change, the pfSense team decided to pull the original implementation of WireGuard from their operating system.
* * * * *
The UBports team have published a series of updates concerning the mobile project and its developments. The blog post includes updates on the distribution's migration from its Ubuntu 16.04 base to 20.04, development efforts on new platforms, and GPU acceleration. "Domubpkm asked about GPU acceleration on Android 9 devices. Is that headed for OTA-17? There are issues not just with Android 9 devices but with all devices, including the PinePhone. There is quite a lot of work and testing needed still so OTA-17 is optimistic. If it works well for PinePhone for example but not for others we may consider a selective release. Not all devices have issues but on some there is for example a 128x128 pixel area of the screen which for some reason freezes."
* * * * *
These and other news stories can be found on our Headlines page.
|
| Questions and Answers (by Jesse Smith) |
Strange, unusual, and fun things to do with Linux
Seeking-unusual-benefits asks: I'm always looking for neat stories and ideas of things to do with Linux. What is one of the coolest/weirdest things you have done with Linux?
Jesse answers: While I try to come up with a memory of something interesting or cool I've done with Linux, I can easily tell you one of the dumbest things I have ever done with a Linux system:
mv /lib/libc.so.2 /lib/libc.so.2.backup
A little context here might help. At the time, back around 2001, I was running an RPM-based distribution and, for some reason, the system's C library had failed to upgrade through the rpm package manager. To work around this, I downloaded the source code for the C library and compiled it. My plan was then to make a backup copy of my existing C library, in case anything went wrong. Finally, I would move the newly compiled, updated version of the library into place, overwriting the original. In short, the two commands should look like this:
cp /lib/libc.so.2 /lib/libc.so.2.backup
mv libc.so.2.0 /lib/libc.so.2
My brain mixed the two commands together and, instead of copying the original C library, making a backup, I moved it. Since virtually every program on the operating system was linked to the C library, including the mv and cp commands, this basically broke every single program on my computer. I could not move anything, copy files, get directory listings, or do anything that wasn't a command already built into the shell I was running at the time.
Luckily, I still had my live CD I had installed the system from. I booted from the live CD, mounted my now-damaged operating system's filesystem, and copied the moved version of the library back into place. Once the original version of the library file was in place, I could boot back into my distribution and try the upgrade again.
This was one of my early experiences with Linux and one of my first attempts at troubleshooting an issue on the (to me) new operating system. It was quite an educational experience. It also taught me that core programs on Linux, unlike classic UNIX systems, were dynamically linked. Statically linked programs would not have broken and would have allowed me to repair the system without a live disc.
* * * * *
One of the better things I have done with a Linux system happened, oddly enough, at a company I was consulting for which used Windows almost exclusively. One of the system administrators mentioned to me one afternoon that he'd run into a problem. The company had a remote office which we could connect to through a VPN. The company had also purchased some proprietary backup software which would search for new files on the remote file server and sync them to the main office's backup server.
The problem, he explained, was the backup software's license key had expired. To make matters worse, when he called the vendor of the backup software the person who answered the phone said all their sales and technical people were away on vacation. We would not be able to buy a new license key for two to three weeks. Not wanting to skip the daily backups for 21 days, my colleague wanted to know if I had any suggestions.
When I asked him about the remote server and the backup system I learned both had Windows file shares, allowing remote access. So I turned on a Linux box I had handy for something I had been testing and wrote out this little script:
mkdir remote
mkdir backup
mount //remote-office/files remote
mount //backup-server/vault backup
rsync -a remote/ backup/
umount remote
umount backup
The names of the servers have been changed and the usernames omitted, but you get the idea. The script connected to both the remote server and the local backup server. Then it synchronized all the files from the remote server to the one in the office. It was less than ten lines, easy to read and understand, and took about 20 minutes to both write and test run. After confirming it was working, he gave me the green light to run the script every night in a cron job, and that effectively replaced the company's previous remote backup software. They still had another solution in place to rotate backups and manage tape archives, but my tiny script was able to take the place of their expensive, proprietary product without requiring the team to wait a couple of weeks for a new license key, so everyone was happy.
* * * * *
Now that I think of it, one of the solutions I came up with which feels the weirdest or most interesting was something I developed for myself. The situation I was in was probably not all that unusual. I was in one location, behind a firewall that I did not have access to modify. I wanted to be able to remotely access a server and send files (mostly backup archives) to it. However, since both machines were behind firewalls which did not allow remote access through tools like OpenSSH and FTP, I was facing a bit of a problem.
To make matters worse, the remote server could go down for maintenance or to be rebooted occasionally, so I couldn't rely on setting up a solution just once and leave it running. What I came up with was a bit unusual. I also had access at the time to a cheap virtual private server (VPS) which did not have much storage space (meaning it could not hold my backed up files), but it was accessible over OpenSSH. And I could go visit the location with the remote backup server occasionally to set up and test a solution.
What I came up with was a two-part solution to give me access whenever I wanted it to the backup server. First, on the backup server I set up a script which would run each time the server was booted. The script basically just ran the following, setting up a proxy connection to the VPS:
ssh -R 12701:localhost:22 jesse@remote-vps
What the above line does is instruct the local machine to connect to the remote-vps server and listen on the VPS computer's network port 12701. Anyone who connects to that port on the VPS will have their connection forwarded to the local, backup machine. In other words, my backup machine was acting in a way which allowed me to connect to it when I was logged into the VPS. From the VPS machine I could run the following and login to the backup server:
ssh -p 12701 localhost
Which meant as long as I could login to the VPS I could also hop over to the backup server, even though the backup server was behind a firewall that did not allow incoming connections. Back at my usual location I could then use OpenSSH to connect to the VPS and run the above command to get onto the remote backup server and run commands. At this point I was just one weird step away from being able to send files to the remote backup server through the VPS.
Before I share the next bit, there are two key pieces of information to keep in mind. The first is that anything piped to the ssh command gets sent to the remote computer and acts just like it was piped from a local command. The second is that the dd program can be used to copy files. The dd program is happy to treat piped input as a file and, if we don't specify an output file, dd will just print its output or send it to the next pipe.
This allows us to read a file using dd, pass that data to the VPS through ssh, and then run another ssh command on the VPS which will connect to the backup server, and finally save the data to a file using dd. None of this requires opening a port in either location's firewall and admin access is not required on any of the three machines. The command to copy a file (such as archive.tar.gz) from my machine at one location to the backup server through the VPS looks like this:
dd if=archive.tar.gz | ssh remote-vps "ssh -p 12701 localhost 'dd of=archive.tar.gz' "
The command is easier to read starting from the inner-most quotes and working outward. The "dd of=archive.tar.gz" part is run on the remote backup server. All it does is take any data sent down the pipe and save it in a file called archive.tar.gz.
The section which reads "ssh -p 12701 localhost..." is run on the VPS and it connects to a local port which is setup by, and forwarded to, the backup server. It then triggers the backup server to run the command in the previous paragraph.
The first bit, "dd if=archive.tar.gz | ssh remote-vps", is the part run on the local machine. It instructs dd to read a file called archive.tar.gz and pipe that data to the remote VPS machine. So each machine is doing one simple task, but the three steps are all strung together into one command.
And that is probably the weirdest thing I have done with a Linux machine. Not necessarily because it was complex, but because I had to work around two firewalls without admin access, and had limited resources on the VPS which prevented me from saving anything temporarily on the intermediate platform.
* * * * *
Additional answers can be found in our Questions and Answers archive.
|
| Released Last Week |
UBports 16.04 OTA-16
The UBports team have announced the release of a new update, UBports 16.04 OTA-16. The new update upgrades the version of the Qt toolkit used with the mobile operating system and introduces several improvements to the Morph web browser. "OTA-16 is the second-largest release of Ubuntu Touch ever (OTA-4, the switch from Ubuntu 15.04 to 16.04, being the largest). In this release, we upgraded the installed version of the Qt frameworks from v5.9.5 to v5.12.9. Qt makes up a massive part of Ubuntu Touch, and using it saves us huge amounts of time while creating software that can scale between phone, tablet, and desktop uses. Upgrading it put us back inside Qt's Long-Term Support cycle and gave us a number of new features we hope to take advantage of in Ubuntu Touch and the Lomiri operating environment. Over 1/3 of the binary packages contained in Ubuntu Touch have changed in this release! This includes not only the various Qt libraries, but also packages that Qt libraries depend on." Additional information can be found in the project's release announcement. Download options and a list of supported mobile devices can be found on the project's Devices page.
Linux Kodachi 8.0
Warith Al Maawali has announced the release of Linux Kodachi 8.0, an updated build of the project's privacy-focused Linux distribution (with VPN, Tor and DNSCrypt) based on Xubuntu 18.04.5. This version upgrades the kernel, brings a new theme and dashboard, and adds a large number of useful tweaks: "Linux kernel upgrade from 5.9.8 to 5.11.7; Kodachi has new brand with new logo, wallpapers, dashboard and system monitor; new dashboard with amazing unique features that you will never see in any other OS, I leave this for you to explore; now you can automatically change your system time zone based on your new IP address; you can have fake hostname for your system; you can see Kodachi source codes and shell scripts in Kodachi system monitor; you can see and monitor all type of system logs in Kodachi system monitor; you can generate passwords with Kodachi; you can verify all Kodachi file sources and system files with s single click; you can disable WiFi Bluetooth RF and block USB devices with a single click; VPN, DNS TOR, Panic room management has totally changed; six types of kill switched were added...." Continue to the changelog for full details.
Linux Kodachi 8.0 -- Running the Xfce desktop
(full image size: 664kB, resolution: 2560x1600 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: 2,364
- Total data uploaded: 36.8TB
|
| Upcoming Releases and Announcements |
|
Summary of expected upcoming releases
|
| Opinion Poll (by Jesse Smith) |
Always-on remote desktop machines
In this week's Feature Story we talked about using an always-on remote desktop service called Shells. This allows people to run a Linux desktop environment from virtually any Internet-connected device, whether it is a phone, laptop, or console. Do you own or rent a remote machine for personal use, whether it's a dedicated server, VPS, or Shells account? Let us know what uses you have for remote machines in the comments.
You can see the results of our previous poll on packet filters in last week's edition. All previous poll results can be found in our poll archives.
|
Running services on remote machines
| I use a dedicated remote machine: | 138 (35%) |
| I use a remote cloud instance: | 43 (11%) |
| I use a VPS: | 84 (21%) |
| I use a Shells account: | 25 (6%) |
| I use another type of remote computing service: | 104 (26%) |
|
|
| Website News |
New distributions added to database
JingOS
JingOS is a Linux distribution for ARM-powered tablet computers based on Ubuntu. It can run desktop Linux apps like VS Code and LibreOffice. The distribution strives to run both GNU/Linux and Android applications.
JingOS 0.6 -- Browsing applications
(full image size: 3.3MB, resolution: 2560x1600 pixels)
Regata OS
Regata OS is a Brazilian Linux distribution based on openSUSE, focusing on desktop and gaming needs. Its main characteristics include a Regata OS store for installing applications and games, out-of-the-box integration with Google Drive, support for a gaming mode via the Vulkan graphics API, an extensive library of games in the Regata OS Game Access portal, support for configuration of hybrid graphics in notebooks, and easy transfer of files between a computer and a smartphone. The distribution's user interface is KDE Plasma.
Regata OS 20.1.4 -- Running the KDE Plasma desktop
(full image size: 1.9MB, resolution: 2560x1600 pixels)
* * * * *
New distributions added to waiting list
- Peropesis. Peropesis is a minimal, independent Linux distribution which runs entirely from RAM.
- DarkOS. DarkOS is an Arch-based, highly minimal distribution which features an optional ncurses-based system installer.
* * * * *
DistroWatch database summary
* * * * *
This concludes this week's issue of DistroWatch Weekly. The next instalment will be published on Monday, 29 March 2021. Past articles and reviews can be found through our Article Search page. 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)
- Bruce Patterson (podcast)
|
|
| 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 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 |
| • Issue 1044 (2023-11-06): Porteus 5.01, disabling IPv6, applications unique to a Linux distro, Linux merges bcachefs, OpenELA makes source packages available |
| • Issue 1043 (2023-10-30): Murena Two with privacy switches, where old files go when packages are updated, UBports on Volla phones, Mint testing Cinnamon on Wayland, Peppermint releases ARM build |
| • Issue 1042 (2023-10-23): Ubuntu Cinnamon compared with Linux Mint, extending battery life on Linux, Debian resumes /usr merge, Canonical publishes fixed install media |
| • Issue 1041 (2023-10-16): FydeOS 17.0, Dr.Parted 23.09, changing UIDs, Fedora partners with Slimbook, GNOME phasing out X11 sessions, Ubuntu revokes 23.10 install media |
| • Issue 1040 (2023-10-09): CROWZ 5.0, changing the location of default directories, Linux Mint updates its Edge edition, Murena crowdfunding new privacy phone, Debian publishes new install media |
| • Issue 1039 (2023-10-02): Zenwalk Current, finding the duration of media files, Peppermint OS tries out new edition, COSMIC gains new features, Canonical reports on security incident in Snap store |
| • Issue 1038 (2023-09-25): Mageia 9, trouble-shooting launchers, running desktop Linux in the cloud, New documentation for Nix, Linux phasing out ReiserFS, GNU celebrates 40 years |
| • Issue 1037 (2023-09-18): Bodhi Linux 7.0.0, finding specific distros and unified package managemnt, Zevenet replaced by two new forks, openSUSE introduces Slowroll branch, Fedora considering dropping Plasma X11 session |
| • 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 | 
Asianux
Asianux was a Linux server operating system which was co-developed by Chinese Leading Linux vendor Red Flag Software Co., Ltd. and Japanese Linux vendor Miracle Linux Cooperation, aiming at the common-standard enterprise Linux platform for Enterprise systems in Asia. It provides enterprise customers with high reliability, scalability, manageability and better hardware and software compatibility. Asianux certification partner program will invite more hardware and software products to be certified on Asianux, and it will definitely help to reduce developing and certificating resources and provide Linux with high quality and low cost. Red Flag Software and Miracle will distribute and market Asianux without any modifications in each Linux distribution package in China and Japan. New products will be based on Asianux and each will be bundled with localised features in each country.
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.
|
|
• 
• 
• 
• 
• 
• 
• 
0x969CD4E778C7b6549A2B00e34114e0168c86A542 
