While I’ve nuked my personal VPS, I still have a VPS that I use for work; it comes in handy for things like running cron jobs, maintaining persistent shells, and generally handling things where a Linux shell seems better than a macOS shell (I’m looking at you, remote PowerShell sessions connecting to Microsoft Exchange.) This week I decided to upgrade it from Ubuntu 18.04 to Ubuntu 20.04. I like to stick on the LTS (long term support) releases for my servers, but I do typically prefer to keep even the LTS releases upgraded rather than waiting for them to go end of life. I could have kept using Ubuntu 18.04 with maintenance updates until 2023 and security maintenance until 2028, but what’s the fun in that?
Upgrading a VPS is always a bit of a nerve-wracking situation just because I don’t have local access to the host in case something goes extremely awry. Ubuntu tries to help alleviate this by opening a second SSH daemon on a different port just in case the primary daemon crashes during the upgrade, but if the machine ends up in a non-bootable state I’m still more or less hosed. Fortunately for me, things almost went off without a hitch… almost.
While the upgrade did complete, I received an error toward the end of the process that GRUB failed to upgrade successfully. This was mildly terrifying since GRUB is the bootloader; if it’s not working properly the system won’t boot, and I can’t access the host of the VPS to troubleshoot it. Luckily, GRUB continued to work in my case, and my system was able to reboot successfully after the 20.04 upgrade and beyond. GRUB just wasn’t getting upgraded. I quickly noticed that I also received an error from GRUB every time I ran sudo apt update && sudo apt upgrade to update my system. Again, the other packages would upgrade successfully, but GRUB would always complain:
installed grub-pc package post-installation script subprocess returned error exit
Errors were encountered while processing: grub-pc
E: Sub-process /usr/bin/dpkg returned an error code (1)
After spending some time just ignoring the problem since it wasn’t exactly critical, I finally decided to do some digging. It turns out that problems like this have apparently plagued Ubuntu upgrades for a while, as I found a thread with the same problem all the way back with an upgrade to Ubuntu 14.04. The solution in that case was to simply “nuke and pave” by removing GRUB and then re-installing it. It’s once again a bit of a white-knuckle situation since if anything happens between removing and reinstalling GRUB the system will not have the ability to boot. The steps were very similar to the linked thread with some minor differences in the era of Ubuntu 20.04. The first step was still to purge GRUB:
sudo apt-get purge grub-pc grub-common
Running this command in 2020 removes /etc/grub.d/ already, so there’s no reason to manually run the removal. Instead, I next moved straight to re-installing GRUB:
sudo apt-get install grub-pc grub-common
The installation process kicks off an interactive wizard asking which disk(s) GRUB should be installed to. In my case, I only needed it on the main disk, which is /dev/sda. With that done, I updated GRUB and then rebooted:
sudo reboot now
This part kind of sucked as I was left running nmap against the SSH port for my VPS and hoping that GRUB was properly set up to allow the system to boot. After a nervous 15 seconds, though, the port started to respond again, and I could successfully SSH into the server. Re-checking for updates showed that everything was fine; the errors about GRUB having a needed upgrade that couldn’t be installed were gone. Admittedly, it was probably unnecessary to go through this upgrade without any specific reason for it, but the beauty of Ubuntu is its popularity. Rarely will there be an issue someone else hasn’t encountered, solved, and documented before, and this problem was no exception.
I wrote about a month ago of an update on my Pinebook Pro after switching to Manjaro Linux. I continue to make heavy use of my Pinebook Pro while I’m still social distancing and staying at home, giving me lots of time to work on personal projects without much else to do.
Today I ran into an interesting issue, though, after applying a round of updates. I mentioned in my last Pinebook Pro post about going through the process of creating a swapfile using the directions from the Manjaro wiki so that I could hibernate the machine and get much better battery life. I literally just opened the device back up, though, and saw a familiar message that there wasn’t enough swap space to successfully hibernate the machine, leaving me with about 20% less battery life than I had been expecting. Running htop quickly showed me that my swap space was back to nothing. Weird.
Following the instructions, my swapfile is literally called swapfile on the root of the filesystem. I verified it was still in place with:
ll / | grep swap
With the file still in place, I ran through the instructions again. These ones were both successful:
Weird. I verified that I still had my swapfile entry in /etc/fstab to assign the swapfile on boot by running:
sudo cat /etc/fstab
I tried running the swapon command a different way to have it apply everything in the fstab file:
sudo swapon -a
This gave me another “Invalid argument” error still referencing “/swapfile”. At this point, I took to the Internet. After a couple of searches, I stumbled across a matching Stack Exchange question. The top answer claims that the issue is the initial fallocate command used to create the file (the same command used in the Manjaro wiki) doesn’t physically allocate the 4 GB on the storage for speed, but that’s apparently problematic for swapon. Following that answer, I ran a dd command to replace my swapfile with something physically allocated:
This takes a few moments to run, especially on the eMMC storage of the Pinebook Pro. Once it completed, though, I repeated the other commands and verified they were all successful. Sure enough, running htop once again shows my 4 GB of allocated swap space.
I had written in early February about my Pinebook Pro laptop after roughly a month of using it. Now that significantly more time has passed, time which I’ve almost exclusively spent at home due to nationwide stay-at-home orders and social distancing, I figure I’d share some of my thoughts on the laptop I raved about initially, and more specifically what I’ve done with the operating system.
If you read my original post then you may recall that I was debating swapping the default Debian operating system for something different. While I mentioned NetBSD in the post I ended up installing Manjaro Linux instead. Why? There are a few reasons to consider.
One of the biggest reasons why swapping the OS can be considered important is that there are some issues with the Debian build that came on my device. It’s a custom setup put together by a community member. It looks incredible, but that comes at a cost; the highly customized environment means that many things in it cannot be updated; this includes both Chromium and Firefox. Running outdated browsers isn’t exactly cool, and I wasn’t too keen on having to compile Firefox from source every time there was a new release.
On the other hand many of the community members seemed to really love Manjaro Linux, so I figured I’d gvie it a shot. Along with people in the Pinebook community raving about it, it’s also been hovering near the top of Distrowatch for a while now. In fact it was announced in March that Manjaro was going to be the default OS for new Pinebook Pro devices, which is pretty slick! They’re shipping with the KDE variant, though, and while I’ve read about people having a good experience with that, I personaly prefer the more lightweight XFCE desktop. It’s lighter, simpler, and overall I feel like it’s a better fit for the Pinebook Pro.
Getting The OS
As something of a noob when it comes to working with open source SoC setups like a Rock64 or Raspberry Pi, I struggled a little with figuring out exactly how to install a new OS on the Pinebook Pro. The first thing I figured out is that, currently, you cannot boot the Pinebook Pro from USB. I made a few bootable flash drives like I would’ve historically used when installing Linux on a more traditional device without success. The Pinebook Pro wiki seems to contradict itself on this point, saying:
The Pinebook Pro is capable of booting from eMMC, USB 2.0, USB 3.0, or an SD card. It cannot boot from USB-C. The boot order of the hard-coded ROM of its RK3399 SoC is: SPI NOR, eMMC, SD, USB OTG.
Then in the very next paragraph it says:
At this time, the Pinebook Pro ships with a Debian + MATE build with uboot on the eMMC. Its boot order is: SD, then eMMC. Booting off USB storage is not currently available, but will be in the future.
I wouldn’t put it past myself to just be misunderstanding something, though, so your mileage may vary. As you might be able to guess from the quotes shared above, I just ordred a cheap microSD card online and used that for the OS installation; everything worked great.
Be aware that if you want to install Manjaro directly on the laptop, be sure to grab the image file with “emmc-installer” in the file name! This is the image designed to be flashed onto the internal eMMC storage of the Pinebook Pro! Grabbing the image without this will simply create a microSD card that will run the OS. This isn’t bad if you’d like to try out Manjaro while leaving the Debian installation on your eMMC, but I wanted to go all-in.
Preparing Your Media
To prepare the media, you can use basically any option that’ll allow you to flash the .img file you downloaded onto the microSD card. You can be old-school and use dd from the command line, but I went easy mode and used balenaEtcher instead.
The boot order on the Pinebook Pro automatically has the microSD card slot above the eMMC, so once you have a microSD card prepared just insert it into the Pinebook Pro, boot the device, and follow the prompts; it’s honestly pretty simple to install. The only catch is a known bug with the 20.04 release where you have to hit Esc while looking at the Manjaro logo after booting from the microSD card before it’ll move forward; as a known bug I would imagine this won’t be relevant for future releases.
When the Manjaro logo has been present for about 15 seconds, press ESC (this is a bug, we know).
Once it’s all done, you boot to this gorgeous view!
For the most part, Manjaro works like a complete dream, and I’ve been extremely happy with it. There are just a couple of caveats that might be worth mentioning, though.
First, there was a bug when running the initial software update on the factory image. First I had to figure out how to update it, but after some quick DuckDuckGo-fu (since I’ve really only used Debian-based flavors of Linux before) I figured I could update Manjaro via:
sudo pacman -Syyu
Note that you can aslo just click the little shield icon in the bottom-right corner of the screen. Regardless of method, though, immediately after booting my new OS I would get the following error when attempting to update:
Conflicting files: nss /usr/lib/p11-kit-trust.so already exists in filesystem
Another benefit to choosing Manjaro is that it has an extremely active community, so it’s easy to search on errors like this and get solutions! I quickly found a YouTube video covering this error and providing the solution:
After that initial update succeeded I’ve been able to perform subsequent updates without needing the --overwrite parameter. Updating via the GUI also works.
It’s entirely possible I just made a mistake in my installation, but I eventually realized that I didn’t have a swap partition or file. I realized this because I noticed that the battery drain while under suspend was a bit severe; I was losing roughly 6% of my battery per hour. This meant that leaving the device on suspend for a day would completely drain a full battery. I changed my XFCE setting so that when closing the lid of the device it would hibernate. This gave me an error, though, that I didn’t have enough swap space to hibernate.
I checked the output of htop and realized that I didn’t have enough space because I didn’t have any swap. Luckily for me, the Manjaro folks have a wiki page dedicated to exactly this; I ended up following the steps to create a swapfile rather than adjusting my partitions to have a swap partition. Since there are 4 GB of RAM in the Pinebook Pro, I ended up creating a 4 GB swap file. Once it’s created you can verify it by looking at htop or running swapon. If you’re concerned about the amount of storage on the eMMC, you can see how much you’re using via:
df -H | grep /$
Typing and the Touchpad
One thing I’ve noticed on occasion is that typing does not disable the touchpad on the laptop, meaning that it’s easy for your hand to accidentally brush it, clicking somewhere else and causing a bit of havoc on whatever it is you’re trying to do. I’ve accidentally done it once just while working on this article. I’ve not found a solution for this yet (I’ll update the post if I do), but it hasn’t been a big deal for me. It’s just something to be mindful about.
On the whole, I’m extremely pleased with my switch to Manjaro. If you’re running a Pinebook Pro with the original Debian build, I’d highly recommend giving Manjaro a shot; it honestly feels like a whole new device afterward.
In my last post about not using Chrome OS, I neglected to get into what I was replacing my Chromebooks with since that seemed like a lengthy post in its own right. As the title gave away, my switch went to the Pinebook Pro from Pine 64. I had been interested in the original $99 USD Pinebook when that came out a couple of years ago, but it seemed a bit too basic for what I wnanted. The Pinebook Pro seemed to offer a more compelling experience for $199. The description on the site even seemed to match exactly what I was wanting.
The Pinebook Pro is meant to deliver solid day-to-day Linux or *BSD experience and to be a compelling alternative to mid-ranged Chromebooks that people convert into Linux laptops.
I didn’t want to have to deal with Windows, nor was I wanting to go through a lot of research to find a Windows laptop or Chromebook that I could then convert to a Linux laptop. The Pinebook Pro seemed to take care of this for me while also giving me an outlet to support a great company doing some awesome things for the open source community. I was a little leery on what kind of performance I would get out of an ARM processor and if I would hit any compatibility issues, but so far everything has been buttery smooth.
The hardware is absurdly nice for a $199 device. The Magnesium alloy body just feels solid and sturdy. It has enough heft to make the laptop feel more expensive than it is without being a pain to carry around. It also just looks sleek given that there’s literally nothing on the top, not even branding. It’s a spotless, black surface.
I don’t normally leave my laptops completely unemblazoned, so I just ordered some stickers for it earlier today. I’ll share pictures on the socials once those are on.
Under the hood is the a screen that you almost feel has no business being on a $200 machine. It’s a 14″ 1080p IPS display that looks absolutely gorgeous. Everything from typing away in a Terminal or blog post to watching videos looks terrific on it.
The keyboard is also surprisingly nice. It’s spacious, and the keys have an impressive amount of travel to them. Given that these days I rarely use my personal laptop unless I’m doing a lot of typing where I need a physical keyboard, the keys on the Pinebook Pro really deliver. Rarely do I even bother to sit at a desk and connect an external keyboard; the default experience is just fine. The keys have good tactile feedback to go along with that travel distance, so you’re never left doubting if you pressed a particular key or not.
You may notice that the keyboard also features literally the only external branding other than the sticker on the bottom of the device. The super key has a Pine 64 logo on it, which is a nice, subtle touch.
The trackpad is unfortunately not quite as solid as the keyboard. It doesn’t feel particular sensitive and the pointer come across as “floaty”. Hitting big buttons is fine, but it can be annoying to make more precise movements like grabbing the corner of an application to resize it. If I’m using the device for something that’s mouse-intensive, I’ll typically reach for my Logitech MX Ergo trackball, but the trackpad is still workable in a pinch.
The speakers aren’t bad, but they’re about what you expect from laptop speakers. Only Apple seems to posess the voodoo required to make great sounding laptop speakers.
The device comes with a barrel jack charger. You can also charge it via the USB-C port as well, which is what I much more commonly do with the charger which came with my Acer Chromebook 315.
Once the device is booted, you’ll be using a customized Debian Linux version that comes from the factory.
Being that it’s Debian Linux, you can do pretty much anything else that you’d expect with Debian Linux… and that’s awesome. There are some limitations in the packages simply regarding what software supports ARM and which software does not, but everything I’ve tried to do so far has worked fine. That being said, I’m mainly still using the device very similar to a Chromebook; I want a web browser and a Terminal.
The ARM processor and included 4 GB of RAM do an excellent job of keeping everything snappy. It’ll occasionally take a little bit longer to launch a heavier application, but otherwise it’s often easy to forget that I’m on a $200 Linux laptop and not my $2000 MacBook Pro for work. The 64 GB of local storage is a nice change from most Chromebooks as well. Rarely is my system ever bumping its head against the hardware, even when I’m streaming music and have a bunch of browser tabs open.
Need to install something new? Just sudo apt install package-name and you’re good to go! That being said, just like normal with Debian you get a wide array of software out of the box… all of which still only amounts to a 5 GB footprint in what comes from the factory.
There are a few things to do out of the box when you get a Pinebook Pro; I would highly recommend reading the wiki page about the device so you know what those are instead of trying to do things on your own. For example, there’s no traditional “first run” experience to set things up given that this is a highly customized Debian image. Instead, you log in with the default credentials rock/rock to get things started. It’s highly recommended you rename the rock account if you want to keep all of the customizations. If you make a brand new account, which is totally an option if you want to go that route, you’ll end up in a session that looks much more like a traditional Debian installation.
While the Wiki does an awesome job of covering what to do when you get the device, my recommendations are:
Overall, I’m extremely pleased with the Pinebook Pro so far. They’ve got a great community, and I’ve spent a little time so far keeping tabs on their IRC server and Discord. If you can’t find something in particular on the wiki (which would be surprising; it’s extremely well-maintained), the helpful folks on IRC can likely assist. If you’re a fan of budget laptops but want to move away from Chrome OS or Windows, the Pinebook Pro seems like a great option if you feel comfortable with Linux.
Do you trust your Internet service provider? If you answer that question with a resounding “No!”, then you’re among friends here. While Internet connectivity is an essential need for many of us, there are a plethora of reasons to be wary of the company providing that connectivity to you. Especially in the United States, the recent repeal of net neutrality rules and erosion of privacy mean you may want to obscure exactly what you’re doing from your Internet provider, even if that activity is completely legal and innocuous. Just because I’m not doing anything illegal online doesn’t mean I want to allow my ISP to gather data on what I’m doing in order to sell it to advertisers; in my opinion they make plenty of money off of the monthly fee I pay them for Internet access.
This is where a VPN (virtual private network) can come in handy, as we discussed in Episode 8. VPNs are historically most common in the corporate world. They allow employees to create a secure tunnel between wherever they are and their internal company network in order to access resources that aren’t available to the outside world. In the consumer space, though, they’ve been gaining popularity as privacy-conscious consumers look for way to protect themselves from things like public WiFi and, increasingly, ISP data collection.
Note: This post is not going to cover the potential risks for a VPN or how to choose one. We recommend you check out guidance from sources like the EFF for that. Brandi and John personally recommend either Private Internet Access or TunnelBear. Check out Episode 8 for more details!
As we’ve discussed in a few podcast episodes, I happen to be a fan of Chromebooks as my personal laptop. While I have a beefy desktop to use as a gaming computer or when I need to do some heavy lifting, I like having a Chromebook as a cheap, fast, and easy computer for things like browsing Reddit, watching YouTube videos, and typing up blog posts. The addition of a Linux VM means I can even do some programming. VPNs get a little wonky on a Chromebook, though. Most VPNs offer applications for Windows, macOS, Android, and iOS. Many services will also support configurations with the OpenVPN Connect client in case you want to use something open source and/or are running some flavor of Linux. For example, Brandi subscribes to Private Internet Access. On her MacBook, she simply runs the PIA application, selects the endpoint she’d like to direct her traffic to, and is done.
The waters get murkier in Chromebook land since you don’t install traditional applications on them. You also have to consider the scope of where you’re working on a Chromebook and what it is you’re looking to protect. Are you just concerned about securing the data flowing through the Chrome browser? Do you need to cover system level networking? Are you doing anything online via your Linux VM that you want to secure? These all play a role, and hopefully this post will enlighten you as to the reach of the options at your disposal.
The first step to testing the scope of VPN clients on Chromebooks is to be able to figure out what your external IP is since that can tell you where the outside world sees your connection coming from, be it your home network or a VPN provider’s. I personally like I Can Haz IP for that. Simply going to the site will give you a web page with your public IP address. Here we can see the result I get from my Chromebook with no VPN solutions at play.
The really cool part about this service is that if you bounce an HTTP request off of it from curl, it’ll reply with your public IP address. This easily allows testing of VPN providers from a command line. If you don’t have curl in your Linux VM, you can easily install it via:
Here we can see what happens when I curl against I Can Haz IP from my Linux VM on my Chromebook. Note that it matches the public IP I get from my browser.
If you have an older Chromebook that doesn’t feature Google Play support, there are several VPN providers (including both PIA and TunnelBear) that offer Chrome extensions. These can be great for quickly proxying your traffic in a pinch. After flipping the switch on the TunnelBear extension, for example, I can see that the endpoint I’m seen as coming from via my browser has changed.
It’s important to keep in mind, though, that the VPN is operating at the application level rather than at the system level. Only traffic from my browser is going through the VPN. As a result, running curl again has no change; my Linux VM’s traffic is still going straight out through my ISP.
This is what we refer to as a bummer. If you happen to have a Chromebook with Google Play support, though, there’s a better solution available. Updates to Chrome OS 75 in the spring of this year resulted in better integration between Android VPNs and Chrome OS as a whole. Installing an Android VPN client from the Play Store and connecting it will result in the WiFi icon in Chrome OS changing to display a tiny key icon, just like you’d see in the notification area of Android. After making this connection, I can verify that my browser shows my connection as coming from my VPN provider.
Even better, though, checking from my Linux VM now shows the same thing; the VM’s traffic is now also going through my VPN provider instead of to the prying eyes of my ISP.
Suffice to say, this is much better. While the Chrome extensions are passable for older Chromebooks without Google Play access, the corresponding Android applications will offer far superior coverage if they’re an option on your particular device. Not that you shouldn’t have already been doing this anyway, but this should be an incentive to avoid purchasing the insanely cheap Chromebooks that so frequently go on sale; I’d recommend making sure you get a device that at least has Google Play and Linux support. Keep encrypting that traffic, and stay pink!
Note: In my testing, the Linux VM in Chrome OS would often struggle to reconnect properly after an Android VPN application was connected and/or disconnected. For the best results, I’d recommend launching the VM after connecting your VPN. If you forget and connect your VPN after the fact, shut down your VM and restart it.
As we’ve mentioned in a few podcast episodes, I happen to be a fan of Chromebooks. I have a hulking desktop that I use for things like gaming, programming, and photo editing. That same desktop is also extremely loud and generates enough heat to warm my apartment, whether it needs to be warmed or not. As a result I tend to like having a cheap Chromebook handy when I just need to take care of some email, catch up on my RSS feeds, waste time look at memes on Reddit, or writing posts for our podcast. I’ve had a handful of Chromebooks over the years, and I’ve always been happy with them given that, for me at least, they serve as supplementary for my personal computing needs. I feel like I’d struggle more than a little if a Chromebook was my only computer.
That being said, my previous Chromebook, a Toshiba Chromebook 2, was getting fairly long in the tooth, and I was on the hunt for a new one to replace it. Chromebooks had been undergoing improvements since I purchased the Chromebook 2, but while the device tended to make the list of ones which were allegedly slated to gain access to the Google Play Store and Linux apps, that never seemed to manifest. I had been eyeing the Acer Chromebook 315 and the HP Chromebook 14, as these were the first two Chrome OS devices to feature AMD processors. That seemed pretty slick to me as I’ve long had AMD hardware over Intel and Nvidia; getting nearly the same performance for significantly less money always seemed like a win for me. Ultimately, I pulled the trigger on the Chromebook 315 when Brandi let me know that it was on sale for around $200 during Prime Day, down from the normal $279. $279 itself still isn’t much of a laptop, but again… it’s a Chromebook. I also don’t actually have Amazon Prime, so Brandi did me another solid by ordering it for me, and I just paid her back. She’s awesome, isn’t she?
At any rate, this isn’t titled as a review because I hate the idea of trying to numerically score things. Instead, I figured I’d just write up some thoughts on the device now that I’ve been using it for about a month. I figure I’ll make a similar post for my (relatively) new Pixel 3a XL sometime in the near future, too.
Aside from the AMD A4 processor, the Chromebook 315 is pretty standard fare for a mid-range Chromebook. 4 GB of RAM and 32 GB of solid state storage get you up and running. The A4 processor seems to do a pretty solid job of handing most of what I’m using a Chromebook for, which is running a handful of tabs to browse the web, writing code in a text editor, or scrolling through endless memes and videos on Reddit. Even with around 10 tabs and a few PWAs running (the Spotify one kicks ass and takes names), I haven’t noticed any real slowdown or issue. The storage space could potentially be a sore spot, though, and I’ll discuss why in a little more detail when we get to the software section.
The device itself is all plastic, as you’d expect for a laptop that’s only $279 dollars on a bad day. It at least feels solid, though, and isn’t creaky. As a 15” laptop, it weighs in at just under 4 lbs., which seems neither particularly bad or impressive. The hinge for the lid is extremely stiff and almost uncomfortable to pry open from a completely closed position; it would be damn-near impossible to do with a single hand. But the trade-off to that is the screen doesn’t wobble at all, even when quickly typing while the device wrests on an uneven surface like your lap.
The lid features a textured pattern, which concerned me a little bit since I wasn’t able to find any detailed photos or videos of it. I had been worried that, like the Toshiba Chromebook 2, the texture would actually keep me from applying stickers to it. Fortunately, that wasn’t the case at all. My sticker game remains firmly on point. Also, most of my stickers came from Brandi so don’t give me credit for my taste. Did I mention she’s awesome?
The battery is rated for 10 hours. To be honest, I’ve left the device sit for days and days at a time without touching it, so I can’t accurately judge the length. I can say that I’ve only had to charge it a handful of times since I got it, though. Running Android applications does seem to to drain the battery at a faster clip, though the screen is the biggest culprit as you’re all but required to have the brightness cranked up pretty high under all circumstances.
Why does the brightness need to be turned up all the time? Because the display is absolute garbage. It may very well be the worst display I’ve ever used on a laptop in my entire life, and that’s no exaggeration from someone who has been using laptops for over a decade. You may be tempted to look at the baseline model and assume that’s because it’s running at 1366 x 768. It’s true that I had been hoping to get the 1920 x 1080 model, but that variant wasn’t on sale during Prime Day and at the time was $70 more. Paying $340 instead of $200 for a laptop just to get a higher resolution screen didn’t seem particularly worthwhile to me, especially when I already had to adjust the text scaling on my 13” 1080p Chromebook 2 so that my myopic ass could actually read anything without my face two inches from the screen. All-in-all, I wasn’t that bummed about the resolution.
The problem is just that the display is horribly washed out. It’s literally incapable of making a color that isn’t pastel. Gray text on an off-white background on a webpage is all but impossible to read with the brightness below 75%. Even when watching videos, the colors are all a lighter hue than you’d expect. While the hardware will easily push the pixels on a display of this low resolution, I’d recommend against this for a device aimed at video. At least the viewing angles are pretty good?
The speakers are fine. They aren’t great, but being mounted facing up does make a massive difference when compared to other devices I’ve used where the speakers are pointing down underneath the device. I’ve been able to easily listen to Spotify on it without being irritated with the sound or any distortion or vibration.
Ports and Connectivity
Awesome enough, the device features two USB C ports and two USB A ports. Having a USB C port on either side of the device is pretty awesome. One of them will commonly be used for charging; it was nice to see that as the charging solution rather than yet another proprietary connector.
The keyboard is middling at best. I know, I know… for a $279 dollar device, are you expecting a good keyboard? Well… kind of? I’ve owned an Acer CB3-131 before, a device which retailed for $179 and which was made by the exact same company. The keyboard on it was actually significantly better than the one on the CB315. The spacing between the CB315’s keys are good, but typing on it just feels bad. The keys are extremely squishy; it’s very difficult to tell if you’ve actually pressed a key adequately or not while typing quickly, leaving me with a not-insignificant number of missed characters when I’m hammering out these posts. Admittedly, part of that stems from the fact that I’m used to spending most of my time typing on a mechanical keyboard, but I still expected something at least a tiny bit better. That being said, it works well enough for quick tweets and Reddit posts. For longer posts like this, though, I’m more likely to dock it in my work-from-home setup and type on a Razer Blackwidow Tournament Edition Quartz.
It’s a touchpad. It works. It’s exactly what you expect; it’s simultaneously:
The same as every other Chromebook trackpad
Better than every PC trackpad
Worse than every MacBook trackpad
This is where things get interesting for me. I could very easily find from doing searches online prior to purchasing the device that it had Google Play support. This means you can access the Google Play Store just like you would from an Android phone and install any apps you may happen to want. They might look a little janky (because what phone display has a maximum vertical resolution of 768 pixels in 2019?) but they work and they tend to run pretty smoothly. I even tried out a couple of games and found them pretty pleasant. What I was really curious about, though, were Linux apps. On supported devices, you can essentially install a Linux VM and get access to a shell with a full Linux system running underneath it. For the most part, compatible devices depended upon having the appropriate processor architecture, so I wasn’t sure if an AMD processor would throw a wrench into things. Mercifully, that wasn’t the case. I was able to just search the settings for “Linux”, toggle it to on, wait a minute for a download, and then I was up an running.
As you can see here, the VM you get is (at the time of this writing) running Debian 9. You can treat it basically like any other Debian install, including installing the packages you need from the repository. Is the repo missing something you really need? Just download and run the .deb file. Linux aficionados like myself will immediately feel at home.
I was able to quickly configure Vim and Python3 along with using the lovely rustup toolchain to install the latest version of Rust. All of them work perfectly. This was huge for me because it means I can do some scripting and development on my Chromebook directly. This without having to use which I’d previously do, which was either sit at my loud, furnace of a desktop or use my Chromebook to SSH into a development server.
The one downside to all of this is that 32 GB hard drive. Getting Debian installed took about 2 GB on its own. When you start adding in some Android apps, copying over a few ebooks, and of course take into account Chrome OS itself, I’m looking at 16 GB of remaining space. 50% isn’t a huge issue for me right now, but if I start needing to add a lot of additional Linux packages or Android apps then things could get tight rather quickly. I may have to investigate swapping out the storage in the future if I start to bump my head.
On the whole, I’m pretty happy with the CB315, especially considering that I paid around 70% of the normal price for it. If I had paid the full price I think I’d still be happy but I’d be slightly more disappointed with the display. It really is atrocious. Chrome OS has come a long way since when I first started using it in 2013, and as a Linux fan it now has so much more value than it did previously. I still don’t think I’d want to roll with a Chromebook as my only personal computer right now, but I can certainly do more with it now than I could before.
In Episode 11, I had discussed how I run a couple of my websites on a Linux server running Nginx as the web server and encrypting connections to them via Let’s Encrypt certificates. Shortly after recording that episode, though, I realized I had messed up my certificate configuration via certbot. If you don’t recall the episode, I had taken my web server which was only running laifu.moe and added awk.ninja to it so that I had both sites running on the same server. When I added awk.ninja, I had to re-run certbot and get a certificate for it along with the certificate I had for laifu.moe. That’s where I messed up; I got tipped off when I received the following email from Let’s Encrypt letting me know that my certificate for laifu.moe was about to expire.
That seemed odd to me since I knew I had a cron job running to update the certificates. I checked the expiration for the certificate on laifu.moe and saw that it had nearly two months left on it. I checked the certificate applied to awk.ninja and saw the same thing. EXACTLY the same thing in fact. In double-checking the certificate on laifu.moe, I realized that the Common Name was for awk.ninja. I was using the awk.ninja certificate for both of my sites. Oops. What happened was that when I added awk.ninja and re-ran certbot, I got the following:
My thought at the time was that I needed to select ALL of the sites. In reality, this overwrote the configuration I already had on laifu.moe and applied the awk.ninja certificate to both sites. This is where I decided to be really stupid. I decided that I would delete the existing certificates, re-run certbot twice (one for laifu.moe and once for awk.ninja), and then be done. I started off by deleting the awk.ninja certificate that was applied to both sites:
I did the same to delete the laifu.moe certificate. Then I tried to do a vanilla run of certbot to get the menu in my screenshot above and individually configure each of my two sites. Instead of getting that menu, though, I received an error message that my sites were pointing to certificates that didn’t exist. certbot then exited without giving me any further options. The problem is that my configuration files below still referenced the certificates that I just nuked. Oops.
After thinking about it for a few seconds, it made sense; certbot can’t know what’s going on and is expecting me to do some cleanup on the mess I made instead of making assumptions about whether or not I should still have certificates. To keep my life simple, I decided to go back to a clean slate on my sites-available configurations since I knew that I could get certbot to redo the configuration again as long as I could get it to successfully run. As a result, I just set the configurations for both laifu.moe and awk.ninja back to a super vanilla setup. Just %s/laifu.moe/awk.ninja/g on the file below for what I configured on awk.ninja.
Once I had that done, I restarted nginx just to make sure it was working and I could hit port 80 for both sites.
With that working, I was able to re-run certbot and finally get the menu from my initial screenshot. I first configured a certificate for awk.ninja and its www variant. Once that was done, I ran certbot one more time and walked through getting a certificate for laifu.moe and its www-variant. In both instances, I opted to have certbot reconfigure the files in sites-available to redirect all HTTP traffic for HTTPS. I restarted Nginx one more time and finally I had everything configured the way I wanted with each site using its own certificate.
The moral of the story is to actually troubleshoot the problem instead of just starting off by deleting shit from your server. Also, try staying pink!