 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 |
|
|
| Reader Comments • Jump to last comment |
1 • Opinion Poll (by Guido on 2021-03-22 01:39:22 GMT from Philippines)
I miss an option: I don't use any remote running service or remote machines! This is for me the case. The easier option is probably the laptop or netbook, that you can bring to work and take home.
2 • SHELLS. Closed source, commercial version of ?? (by Greg Zeng on 2021-03-22 01:40:49 GMT from Australia)
> "Access Windows From Any Device"
> "Turn Your Ipad or Chromebook into a Windows PC"
> "Any web-enabled device, ... can connect to Shells."
No mention of Apple, Raspberry Pi, etc. Distrowatch lists 50 "shells", excluding many web browser & VPS products. Seems to me that this commercial product is another version of the standard CLI, VPS, desktop environments, etc.
All products, both commercial & open source, have bugs, versions, limitations, etc. As end-users, we expect these parameters to be explained to us.
3 • Shells - fast setup (by Andy Prough on 2021-03-22 02:20:17 GMT from United States)
@Jesse wrote: "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."
A personalized snapshot of antiX can usually be installed in 2-4 minutes in my experience. A personalized snapshot of MX might take a couple minutes longer, but not much. At least with respect to antiX and MX, there would be no real noticeable advantage in terms of time savings.
4 • Entropy Piano Tuner (by mmphosis on 2021-03-22 03:14:27 GMT from Canada)
The most unusual thing I've done with Linux is use the Entropy Piano Tuner to tune a piano.
5 • Shells - spare Me! (by Bobbie Sellers on 2021-03-22 03:18:52 GMT from United States)
I have not bothered with distributed computing of any sort in the 45 years or so I have
been using personal/home computers. I find the suggestion of moving personal sensitive
material to and from the Shells system is a big security hole and begs for the need to
back up everything that you do there.
I prefer my own choice of OS running on my own computer where the mistakes can
all be blamed on my administrator namely myself.
bliss - “Nearly any fool can use a Linux computer. Many do.” After all here I am...
6 • Strange, unusual and fun (by Gary W on 2021-03-22 03:44:42 GMT from Australia)
...I think so, anyway :-)
I record free-to-air TV with Kaffeine (on a dedicated computer in the "box room"), play back with mpv, and manage with mc. Kodi didn't work for me, when I last tried it. I don't watch it live, I have regular TV hardware for that. Still missing me-tv :-|
As for Shells, yes I can see the benefits, but as a lifetime geek, I'm with @5, I prefer the freedom to mix and match my own choices of hardware and software.
7 • Dumbest Things (by Wedge009 on 2021-03-22 05:10:07 GMT from Australia)
Thanks for being brave enough to share that 'dumbest thing' story. I had a similar experience with DOS, on my dad's computer when I was in early high school or late primary school. USB flash drives were still several years off and portable storage was most commonly 3.5" diskettes, usually mounted as 'A-drive' in DOS.
I wanted to clean up my disk when I was done with my work for the evening, so I wrote 'del *.*'. To my horror, I realised the prompt was at C: instead of A:. Thankfully when my father returned we were able to recover the OS but I learned my lesson. Not quite as dumb as 'rm -rf /*' but pretty close.
I also like the story about replacing the expensive proprietary back-up software. Always fun to show how *NIX can replace Windows. There may be a time and place for Windows software, but a lot of the time it's just a case of being comfortable only with what they are familiar with.
---
Like some others who have commented before me, I'm also don't have any need or want for remote computing so abstained from the poll.
8 • dumbest or possibly weirdest (by Matt on 2021-03-22 05:35:45 GMT from United States)
I uninstalled a running kernel once on a machine that only had one kernel installed. That was probably the dumbest thing I did when learning Linux.
The most painful lesson I learned was not specific to linux:
Years ago, my main desktop computer at work went dead. I assumed that the power supply failed. When the power button was pressed, nothing happened. I hadn't backed up data in two weeks. Rather than trouble shoot anything, I took the hard drive home with me to get the data off it. I opened up my desktop computer at home and installed my work hard drive as an additional drive. When I pressed the power button, nothing happened. My home computer was now dead too.
Somehow the hard drive failed. The failing hard drive somehow caused the motherboard to fail. Now I had two dead computers, and neither one had been backup up recently.
I got prices on forensic data recovery from the broken drive. You'd be amazed at how expensive that is. I decided I'd just lose two weeks of work instead of paying the extreme cost of trying to get the data off the disks.
Ever since then, my work machine uses RAID 1 and I back up regularly.
9 • Shells (by Any on 2021-03-22 05:49:24 GMT from Spain)
Shells - another step to the cloud computing.
No, thank you.
10 • Shells, 5 & 9 (by Someguy on 2021-03-22 07:49:06 GMT from United Kingdom)
Agreed. Nil response in Poll this week. Running several machines with interchangeable drives, swapped, backed-up and cloned regularly - none ever leave my control. Just how difficult is it to carry an SSD on your person if necessary?! 'Cloud' is just a by-word for your data on someone else's server. Don't do it , sooner or later they'll want $$$ or worse...
11 • Shells Remote service. Trust no way. (by Hank on 2021-03-22 08:26:39 GMT from Germany)
For the price of giving my data to a more or less unknown company, having a crappy browser dictated and the monthly bill no way way I would ever use this kind of disservice.
12 • The most crazy task on Linux (by Alexandru on 2021-03-22 09:54:47 GMT from Austria)
It was a time when BTRFS was not available in Linux, but it was era of ReiserFS. Mainstream kernel supported it and I never had any problem with it. At that time much hope was put in Reiser4 filesystem. It never arrive to mainstream Linux, so I downloaded kernel source, Reiser4 patch, applied it and compiled the kernel. But than no Linus installer offered an option to install Linux onto Reiser4 formatted disk.
So I start playing. I divided the hard disk into 2 large partitions and installed Linux on ReiserFS on the 2nd one. Then I put freshly compiled kernel with Reiser4 support, installed reiser4progs and formatted the first partition as Reiser4. I then mounted that partition and copied the whole Linux installation to the 1st partition.
The next problem was no Linux bootloader was able to read Linux kernel from Reiser4 partition. So I formatted small swap partition to ReiserFS, copied kernel and grub configuration to it and configured /etc/fstab to use this partition as /boot. I reinstalled GRUB and viola, it worked!
When I finally could boot into Linux on Reiser4 partition, I deleted large Reiserfs partition where the Linux was firstly installed, created one more small partition for swap and one large partition for /home.
I enjoyed that experience. However I had many other issues with that kernel, so I ended up using mainstream kernel and supported filesystems.
13 • Shells review (by Otis on 2021-03-22 14:46:49 GMT from United States)
After reading all that, and "There are limitations to Shells, such as requiring a quick, stable Internet connection to access it" I truly LMAO.
But, hey, maybe it'll get big like AOL did. For. A. While.
14 • BAD DAY (by Bob on 2021-03-22 14:48:58 GMT from United States)
I accidentally deleted my storage partition with all my docs, music, videos, etc.
PANIC-MODE!
I got on another computer and searched for a solution. I found a way to recover it from the command-line by installing testdisk on a live-linux disk. Worked perfectly. Everything was BACK!
https://www.simplified.guide/linux/disk-recover-partition-table
15 • SSH Tunneling (by Luke on 2021-03-22 14:49:20 GMT from United States)
Great story in the Q&A. I consider myself pretty handy with SSH, but SSH Tunneling is still a bit like black magic to me. I don't use it often, so when I do I have to look up how to use it, whether to use -L or -R, where to start the tunneling process, etc.
Not sure I have any cool stories, except I went through a phase where I put Linux on everything I could. My PS3, a PogoPlug, my router, etc. I ran a super custom version of Arch on my laptop where I ran plain OpenBox and wrote a couple of the GUI tools myself using Python. I still have a couple of those $9 CHIP computers that I've used to set up webservers, openVPN servers, etc.
One of my laptops, on which I was dual-booting Linux and Windows, received almost 32 oz of strawberry lemonade directly to the keyboard about 8 years ago now. It obviously shut itself down, I called it a loss, bought a new computer, installed Linux on the new one, and moved on. But then, on a whim, I tried to turn it on. It worked. The keys were sticky (and a few like Esc don't work), the fans whined, the hinges were a little rough, but it actually worked. But only my main Linux install did. Windows wouldn't boot, my distro-hopping partition wouldn't boot, but miraculously, the laptop worked. It still runs to this day, in fact, and I boot it up once or twice a year, on the rare occasion when I need to use the CD/DVD drive. I think there are probably bad sectors on the RAM and HDD, so it's probably just happenstance that Linux works and not Windows, but it's still kind of a fun story.
16 • Shells... a Linux DaaS solution (by Scott Dowdle on 2021-03-22 17:11:57 GMT from United States)
I was curious as to which remoting protocol (or variant) Shells might be using. Scouring their website revealed nothing... but I did use their contact form to ask. Maybe they'll send me a reply.
I did download their client and run the strings command on it. Nothing really stood out.
I have setup desktop environments on cloud-based systems several times. x2go would be my preferred remoting protocol but it is getting long in the tooth and is lacking in good client support these days. VNC is so close to be usable... especially the noVNC javascript client that runs in a browser... but copy and paste doesn't work, multi-media doesn't work... and neither does remote device access (USB drives, for example). VNC is fine for simple stuff though.
SPICE has been deprecated in RHEL and was mostly only for KVM VMs. I really like NoMachine's products but I wish there were an FLOSS option for commercial use.
17 • Shells... a Linux DaaS solution (by Scott Dowdle on 2021-03-22 17:17:33 GMT from United States)
I heard back from the Shells folks and they say they are using SPICE. So I guess they use the javascript SPICE client as well as a rebranded SPICE client of some sort. Multi-media via SPICE on a LAN is generally fairly good if you have reasonable PC to run it on... but over WAN, it is one of the more bandwidth intensive remoting protocols comparatively.
18 • Remote Computing (by Simon Plaistowe on 2021-03-22 19:54:34 GMT from New Zealand)
I have no need for such, but the poll has no option for that. I prefer to keep my data and backups on local machines. Unless you count MegaSync, which should allow me to retrieve my most important documents in the event of theft, fire, nuclear holocaust or zombie apocalypse :o)
19 • Shells 16 &17. (by Clicktician on 2021-03-22 23:15:03 GMT from United States)
My experience ditto... even down to pouring a 16oz soda on the keyboard of a Thinkpad x230. Yup. Still works. Those things are tanks.
I'm taking baby steps. Have a fast, headless box running VMware I access with AnyDesk ( a NoMachine protocol derivative). It's just, "ok." I'm exploring options for when I'm older and won't be able to own and house whatever machine I want for a variety of physical security and facility policy reasons. I may only have an internet connection and a throw-away device. And in my experience with people older than I am, that is highly likely. Better to acclimate to a solution now, than to be without options later, as most of them are.
20 • Shells (by R. ain on 2021-03-23 03:23:42 GMT from United States)
Yes, I read Jesse Smith's thorough, very-well-done (as usual) review.
Some here have been, rightly or wrongly, less than complimentary.
I will confine my comments to one simple subject: I simply don't see a compelling reason for the existence of this.
What does it "bring to the party". What compelling reason is there to pay for a "service" (or "services") which any fairly knowledgeable user can create / generate for him-/ herself at no cost; have GREATER flexibility (much!); and not continually be worrying about (a) how often this service will be upgraded to provide state-of-the-art capability, and (b) how long this company is going to be in business providing this "service"--the number of 'big names' which have provided hardware and dedicated software, and then--ignominiously--abruptly decided to go out of that particular business, to not support their grandiose "You Can't Live Without This Whatsis" is now legendary. And have, unfortunately, made the lives of people who develop capabilities such as SHELLS much more difficult.
TL;DR--This is a solution looking for a problem. Can't get past that.
21 • No personal use - maybe business (by M.Z. on 2021-03-23 03:44:32 GMT from United States)
So the Shells thing looks a fair bit like the Citrix remote Desktop I use all the time for work. I open up a remote connection to Windows 10 via a corporate VPN & load up all the specialty software needed to do my job. If the Shells website had desktop preset & ready to tweak for specific corporate tasks I can certainly see the utility. Got Geodata to map & do QA on? Start with a preset Shell package that has QGIS & other essentials pre-loaded & allow the client to add other custom software as needed, so they can quickly bring on remote workers as needed. Got a graphic design project? There could be a Shell package with GIMP & other essentials ready to go, with the option to customize a profile that loads other licensed software & deploy to a team at scale, with as many remote Desktop Shells as needed.
All that is to say I could see great utility in this with some modifications & tweaking to meet possible business needs. That being said the personal use cases seem like they would be far fewer & further between.
22 • Shells (by Alessandro di Roma on 2021-03-23 10:13:38 GMT from Italy)
In order to feed my small Internet site with daily data I don't use a remote machine but a dedicated Raspberry Pi in my home, acting as a H24 microserver. By the way, I see the Shells machine have a public-facing IP address, so I wonder if it can run a public web server.
23 • #22 Web Server (by Shane on 2021-03-23 15:58:53 GMT from United States)
Sure can! By default the Shells share an IP address much like how a VPN does, this way it can't be seen whos running what/doing what and there's no logging. For $1 a public facing IP address can be purchased and then utilized and you can run the desktop as a server a well!
24 • Shells... newest incarnation of an old pipe dream (by Sitwon on 2021-03-23 16:45:47 GMT from United States)
Shells seems like just the latest stab at a very old pipe dream: a ubiquitous computing environment that follows you wherever you go and is available from whatever device you have available.
The appeal of this is simple, rather than managing multiple desktop environments, each with it's own interface/quirks, and trying to keep them all in sync... just have one single desktop environment that you can "bring with you" and doesn't need syncing because the state is persistent regardless of how you're accessing it.
OQO tried to offer this way back with their pocketable computing device.
A few other manufacturers tried to offer this with wallet-sized compute modules that would plug into laptop-like and desktop-like docks.
I've personally worked on a few lazy approaches that combined a live computing environment with some portable USB storage.
Ubuntu/MaruOS are working on this in different ways by allowing your phone to be plugged into a larger display and keyboard to become your desktop.
This is what the "convergence" movement in desktop interface design is all about.
Shells is just the latest stab at this, adding in the factor of "the cloud". And it's a perfectly reasonable and natural evolution. We can see the lineage of this in:
1) Streaming gaming demonstrating that the bandwidth for remote computing exists.
2) The legacy of thin-clients and remote computing from corporate environments of old.
3) The very name "Shells" evokes (for those us old enough to remember) the concept of Unix Shells which used to be the way that students and hobbyists would get access to a slice of resources on a Unix-ish computer allowing us to run long-running Internet tasks/scripts (like servers) without tying up the phone line indefinitely (remember dial-up?). Hacker movies from the 90s still referenced "hacking shells", even as actual *nix shells were dying out online in favor of running Linux locally.
This isn't intended to be a solution for everyone, or even most people. Most of us are probably not the likely audience for Shells. But I do think an audience exists for which Shells (or a very similar offering) would absolutely provide value.
A Chromebook user that needs to occasionally run some Windows software, for instance. A developer or team that wants to test their software on a variety of popular platforms without the hassle of setting up, hosting, and maintaining each target environment themselves. Especially for a distributed team, it allows multiple members of the team to share access to the actual environment in which a bug has been reproduced. Or malware researchers who want to execute untrusted software in an inspectable environment with less risk of leaking their identity to the malware author(s).
25 • cloudy shells (by null recruit on 2021-03-24 04:56:07 GMT from France)
old proverb: "shells can be shucked by skilled phishermen."
no thankyou.
26 • PC in the cloud instead of cloud in a PC (by fonz on 2021-03-24 09:07:10 GMT from Indonesia)
awesome weekly, going for something unique and unorthodox. sure some of the more conservative people may judge it harshly, but there are some good uses BTW. theres always an option to not put more private data on it. wonder when some of the bigger thugs might try this...
im still an active beta tester for both gulag stadia and nvidia (cant think of any new name) now, although both arent available in my country. ive got a special pass for a special person. the ETA for a fully global release is like in, around a lifetime i guesstimate. ive also tried and still use steam (also no new name) link and thought it was nice, and wondered if the next evolution was this.
distrotest was awesome where we could try out live distros before putting any effort to install it to our machines. wonder when theyll spice things up and move from using VNCs.
ive always hated the cloud in a PC approach as many things tend to be bult in to the system. like for example trying to remove all those stuff from KDE and numb might bork everything else. luckily smaller DEs like XFCE and LXQT arent too evil. havent tried mate and cinnamon for a long time, but from what ive remembered they too were nicer. wandows OTOH is just pure insanity, with 9000% chance of more insanity with 11...
27 • Ssh tunnels (by Wally on 2021-03-24 20:16:23 GMT from United States)
In a production environment I supported once, we had our appliances dial home to our admin server on-prem. That way, our support personnel could connect to the appliance boxes for maintenance, upgrades, etc. It was required in the contract to our customers that the devices had ssh access to our admin systems back at the mothership.
I used to need tar z mydir/ | ssh servername "(cd /dest/path/ ; tar x )" or whatever the exact syntax would be. It was amusing. An interesting link, but mostly unrelated, about compression speeds/times: https://www.rootusers.com/gzip-vs-bzip2-vs-xz-performance-comparison/. It mattered what compression format I used because of the compute power versus network throughput to the destination.
28 • Shells — Recycled Idea (by missTell on 2021-03-25 06:42:18 GMT from Switzerland)
I forgot what was the exact name of the Magix's “Cloud OS” some 15 years ago, but I remember that it didn't last for long — as well as some dozen of others.
I can imagine a couple of use cases for such operating systems, but because of their price and limitations, they aren't interesting for a wider audience.
In my opinion, that'll not change any time soon.
https://en.wikipedia.org/wiki/Online_OS
https://arstechnica.com/uncategorized/2008/01/hands-on-with-xios-the-cloud-os-that-runs-in-a-browser/
29 • Ah, memories (by CS on 2021-03-25 20:12:52 GMT from United States)
I did something similar to that, way back in the days of Slackware 4 I think?
cp /lib/libc.so.upgrade /lib/libc.so.oldversion
Learned a thing or 2 that day.
30 • Weird things (by Cheker on 2021-03-25 22:35:44 GMT from Portugal)
Probably the most peculiar thing I've done was live boot into Kali and use dd to make a compressed image of a very old Windows 95 installation that I want to preserve. That PC is probably gonna die any day now. That machine doesn't even have USB ports, I had to connect that HDD to another PC, that's also old but not as much as the 95.
Number of Comments: 30
Display mode: DWW Only • Comments Only • Both DWW and Comments
| | |
| TUXEDO |
TUXEDO Computers - Linux Hardware in a tailor made suite
Choose from a wide range of laptops and PCs in various sizes and shapes at TUXEDOComputers.com. Every machine comes pre-installed and ready-to-run with Linux. Full 24 months of warranty and lifetime support included!
Learn more about our full service package and all benefits from buying at TUXEDO.
|
| Archives |
| • Issue 1100 (2024-12-09): Oreon 9.3, differences in speed, IPFire's new appliance, Fedora Asahi Remix gets new video drivers, openSUSE Leap Micro updated, Redox OS running Redox OS |
| • Issue 1099 (2024-12-02): AnduinOS 1.0.1, measuring RAM usage, SUSE continues rebranding efforts, UBports prepares for next major version, Murena offering non-NFC phone |
| • Issue 1098 (2024-11-25): Linux Lite 7.2, backing up specific folders, Murena and Fairphone partner in fair trade deal, Arch installer gets new text interface, Ubuntu security tool patched |
| • Issue 1097 (2024-11-18): Chimera Linux vs Chimera OS, choosing between AlmaLinux and Debian, Fedora elevates KDE spin to an edition, Fedora previews new installer, KDE testing its own distro, Qubes-style isolation coming to FreeBSD |
| • Issue 1096 (2024-11-11): Bazzite 40, Playtron OS Alpha 1, Tucana Linux 3.1, detecting Screen sessions, Redox imports COSMIC software centre, FreeBSD booting on the PinePhone Pro, LXQt supports Wayland window managers |
| • Issue 1095 (2024-11-04): Fedora 41 Kinoite, transferring applications between computers, openSUSE Tumbleweed receives multiple upgrades, Ubuntu testing compiler optimizations, Mint partners with Framework |
| • Issue 1094 (2024-10-28): DebLight OS 1, backing up crontab, AlmaLinux introduces Litten branch, openSUSE unveils refreshed look, Ubuntu turns 20
| | • Issue 1093 (2024-10-21): Kubuntu 24.10, atomic vs immutable distributions, Debian upgrading Perl packages, UBports adding VoLTE support, Android to gain native GNU/Linux application support |
| • Issue 1092 (2024-10-14): FunOS 24.04.1, a home directory inside a file, work starts of openSUSE Leap 16.0, improvements in Haiku, KDE neon upgrades its base |
| • Issue 1091 (2024-10-07): Redox OS 0.9.0, Unified package management vs universal package formats, Redox begins RISC-V port, Mint polishes interface, Qubes certifies new laptop |
| • Issue 1090 (2024-09-30): Rhino Linux 2024.2, commercial distros with alternative desktops, Valve seeks to improve Wayland performance, HardenedBSD parterns with Protectli, Tails merges with Tor Project, Quantum Leap partners with the FreeBSD Foundation |
| • Issue 1089 (2024-09-23): Expirion 6.0, openKylin 2.0, managing configuration files, the future of Linux development, fixing bugs in Haiku, Slackware packages dracut |
| • Issue 1088 (2024-09-16): PorteuX 1.6, migrating from Windows 10 to which Linux distro, making NetBSD immutable, AlmaLinux offers hardware certification, Mint updates old APT tools |
| • Issue 1087 (2024-09-09): COSMIC desktop, running cron jobs at variable times, UBports highlights new apps, HardenedBSD offers work around for FreeBSD change, Debian considers how to cull old packages, systemd ported to musl |
| • Issue 1086 (2024-09-02): Vanilla OS 2, command line tips for simple tasks, FreeBSD receives investment from STF, openSUSE Tumbleweed update can break network connections, Debian refreshes media |
| • Issue 1085 (2024-08-26): Nobara 40, OpenMandriva 24.07 "ROME", distros which include source code, FreeBSD publishes quarterly report, Microsoft updates breaks Linux in dual-boot environments |
| • Issue 1084 (2024-08-19): Liya 2.0, dual boot with encryption, Haiku introduces performance improvements, Gentoo dropping IA-64, Redcore merges major upgrade |
| • Issue 1083 (2024-08-12): TrueNAS 24.04.2 "SCALE", Linux distros for smartphones, Redox OS introduces web server, PipeWire exposes battery drain on Linux, Canonical updates kernel version policy |
| • Issue 1082 (2024-08-05): Linux Mint 22, taking snapshots of UFS on FreeBSD, openSUSE updates Tumbleweed and Aeon, Debian creates Tiny QA Tasks, Manjaro testing immutable images |
| • Issue 1081 (2024-07-29): SysLinuxOS 12.4, OpenBSD gain hardware acceleration, Slackware changes kernel naming, Mint publishes upgrade instructions |
| • Issue 1080 (2024-07-22): Running GNU/Linux on Android with Andronix, protecting network services, Solus dropping AppArmor and Snap, openSUSE Aeon Desktop gaining full disk encryption, SUSE asks openSUSE to change its branding |
| • Issue 1079 (2024-07-15): Ubuntu Core 24, hiding files on Linux, Fedora dropping X11 packages on Workstation, Red Hat phasing out GRUB, new OpenSSH vulnerability, FreeBSD speeds up release cycle, UBports testing new first-run wizard |
| • Issue 1078 (2024-07-08): Changing init software, server machines running desktop environments, OpenSSH vulnerability patched, Peppermint launches new edition, HardenedBSD updates ports |
| • Issue 1077 (2024-07-01): The Unity and Lomiri interfaces, different distros for different tasks, Ubuntu plans to run Wayland on NVIDIA cards, openSUSE updates Leap Micro, Debian releases refreshed media, UBports gaining contact synchronisation, FreeDOS celebrates its 30th anniversary |
| • Issue 1076 (2024-06-24): openSUSE 15.6, what makes Linux unique, SUSE Liberty Linux to support CentOS Linux 7, SLE receives 19 years of support, openSUSE testing Leap Micro edition |
| • Issue 1075 (2024-06-17): Redox OS, X11 and Wayland on the BSDs, AlmaLinux releases Pi build, Canonical announces RISC-V laptop with Ubuntu, key changes in systemd |
| • Issue 1074 (2024-06-10): Endless OS 6.0.0, distros with init diversity, Mint to filter unverified Flatpaks, Debian adds systemd-boot options, Redox adopts COSMIC desktop, OpenSSH gains new security features |
| • Issue 1073 (2024-06-03): LXQt 2.0.0, an overview of Linux desktop environments, Canonical partners with Milk-V, openSUSE introduces new features in Aeon Desktop, Fedora mirrors see rise in traffic, Wayland adds OpenBSD support |
| • Issue 1072 (2024-05-27): Manjaro 24.0, comparing init software, OpenBSD ports Plasma 6, Arch community debates mirror requirements, ThinOS to upgrade its FreeBSD core |
| • Issue 1071 (2024-05-20): Archcraft 2024.04.06, common command line mistakes, ReactOS imports WINE improvements, Haiku makes adjusting themes easier, NetBSD takes a stand against code generated by chatbots |
| • Issue 1070 (2024-05-13): Damn Small Linux 2024, hiding kernel messages during boot, Red Hat offers AI edition, new web browser for UBports, Fedora Asahi Remix 40 released, Qubes extends support for version 4.1 |
| • Issue 1069 (2024-05-06): Ubuntu 24.04, installing packages in alternative locations, systemd creates sudo alternative, Mint encourages XApps collaboration, FreeBSD publishes quarterly update |
| • Issue 1068 (2024-04-29): Fedora 40, transforming one distro into another, Debian elects new Project Leader, Red Hat extends support cycle, Emmabuntus adds accessibility features, Canonical's new security features |
| • Issue 1067 (2024-04-22): LocalSend for transferring files, detecting supported CPU architecure levels, new visual design for APT, Fedora and openSUSE working on reproducible builds, LXQt released, AlmaLinux re-adds hardware support |
| • 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 |
| • 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 | 
Pear Linux
Pear Linux was a French Ubuntu-based desktop Linux distribution. Some of its features include ease-of-use, custom user interface with a Mac OS X-style dockbar, and out-of-the-box support for many popular multimedia codecs.
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.
|
|
• 
• 
• 
• 
• 
• 
• 
