Running an always on desktop with ShellsShells 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.
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.
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.
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)
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.