In an earlier post, I described how to install the latest version of the Oracle Java JDK using homebrew. What hadn’t been completely obvious to me when I wrote the original blog post is that the ‘java’ cask will install the latest major version of the JDK. As a result, when I upgraded my JDK install today, I ended up with an upgrade from Java 8 to Java 9. On my personal machine that’s not a problem, but what if I wanted to stick with a specific major version of Java?
We all love the odd debugging story, so I finally sat down and wrote up how I debugged a configuration issue that got in the way of the iOS mail app’s ability to retrieve email while I was on the go.
tl;dr – iOS Mail uses IPV6 to access you email server when the server supports IPV6 and doesn’t fall back to IPV4 if the IPV6 connection attempt fails. If if fails, you don’t get an error, but you don’t get any email either.
The long story of why I sporadically couldn’t access my email from the iOS 10 Mail app
Somewhere around the time of upgrading my iPhone 6 to iOS 10 or even iOS 10.2, I lost the ability to check my email using the built-in iOS Mail app over an LTE connection. I am not really able to nail down the exact point in time was because I used Spark for a little while on my phone. Spark is a very good email app and I like it a lot, but it turned out that I’m not that much of an email power user on the go. I didn’t really need Spark as Apple had added the main reason for my Spark usage to the built-in Mail app. In case you’re wondering, it’s the heuristics determining which folder you want to move an email to that allow both Spark and now Mail to suggest a usually correct destination folder when you want to move the message.
I’ve blogged about getting Manjaro Linux to work with my AMD RX 470 before. The method described in that post got my AMD RX 470 graphics card working with the default 4.4 kernel. This worked fine – with the usual caveats regarding VESA software rendering – until I tried to upgrade to newer versions of the kernel.
My understanding is that the 4.4 kernel series doesn’t include drivers for the relatively recent AMD RX 470 GPUs, whereas later kernel series (4.8 and 4.9 specifically) do. Unfortunately trying to boot into a 4.9 kernel resulted in the X server locking up so well that even the usual Alt-Fx didn’t get me to a console to fix the problem.
My adventures with Manjaro Linux continue and I’ve even moved my “craptop” – a somewhat ancient Lenovo X240 that I use as a semi-disposable travel laptop – from XUbuntu to Manjaro Linux. But that’s a subject for another blog post. Today, I wanted to write about package download performance issues I started encountering on my desktop recently and how I managed to fix them.
I was trying to install terminator this morning and kept getting errors from Pamac that the downloads timed out. Looking at the detailed output, I noticed it was trying to download the packages from a server in South Africa, which isn’t exactly in my neighbourhood. Pamac doesn’t appear to have an obvious way to update the mirror list like the Ubuntu flavours do, but a quick dive into the command line helped me fix the issue.
First, update and rank the mirror list:
sudo pacman-mirrors -g
Inspecting /etc/pacman.d/mirrorlist after running the above commands showed that the top ranked mirrors now are listed in the US with very short response times.
After updating the mirrors, it’s time to re-sync the package databases:
sudo pacman -Syy
Now with the new, faster mirrors ranked accordingly, I suddenly get my Manjaro packages and package updates at the full speed of my Internet connection rather than having hit and miss updates that take forever to install.
Turns out it’s not only Windows 8 that has its telnet client disabled, Windows 10 is in the same boat. I’ve been using Windows 10 for quite a while now and just discovered this issue. Anyway, the way to enable is as follows:
I’ve been a Xubuntu user for years after switching from OpenSuse. I liked its simplicity and the fact that it just worked out of the box, but I was getting more and more disappointed with Ubuntu packages being out of date, sorry, stable. Having to rebuild a bunch of packages on every install was getting a little old. Well, they did provide material for all those “build XXX on Ubuntu” posts. Recently I’ve been playing with Manjaro Linux in a VM as I had been looking for an Arch Linux based distribution that gave me the right balance between DIY and convenience. I ended up liking it so much that I did a proper bare metal install on my main desktop. The install was pretty smooth apart from a issue with getting my AMD RX 470 graphics card to work.
This blog is self-hosted, together with some other services on a FreeBSD virtual server over at RootBSD. Yes, I’m one of those weirdos who hosts their own servers – even if they’re virtual – instead of just using free or buying services.
I recently had to migrate from the old server instance I’ve been using since 2010 to a new, shiny FreeBSD 10 server. That prompted a review of various packages I use via the FreeBSD ports collection and most importantly, resulted in a decision to upgrade from PHP 5.6 to PHP 7.0 “while we’re in there”.
I’ve moved from using Apache as a web server to nginx for various projects. The machines I’m running these projects on are a somewhat resource constrained and nginx deals with low resource machines much better than Apache does and tends to serve content faster in those circumstances. For example switching the machine that hosts this WordPress blog from Apache and mod_php to nginx with php-fpm improved the pingdom load times on this blog by about 30% with no other changes.
The last piece of the puzzle was to get newsyslog to rotate the nginx logs. The instructions on BSD Start suggest they’re for FreeBSD 10, but they work fine on FreeBSD 9.x as well.
Yes, I know Ubuntu and Xubuntu already come with Chromium in their official package repositories, but sometimes it does help to have the official/commercial version installed in addition to the Open Source one. I actually both installed right now, plus Firefox and Vivaldi. You could almost think I’m some sort of web developer or something.
The Google Chrome installation instructions for 14.04 on Ubuntu Portal also work fine for 15.04 with one wrinkle. If you use the installation via PPA method, you need to run the following command to actually install the stable version of Chrome:
sudo apt-get install google-chrome-stable
The page above lists the command as
sudo apt-get install google-chrome but that doesn’t work for me on 15.04.
I would recommend installing Chrome via PPA as that will integrate into the automatic update process. One less thing to think about when keeping your machine up to date.
In a previous blog post I explained how you can substantially improve the performance of git on Windows updating the underlying SSH implementation. This performance improvement is very worthwhile in a standard Unix-style git setup where access to the git repository is done using ssh as the transport layer. For a regular development workstation, this update works fine as long as you keep remembering that you need to check and possibly update the ssh binaries after every git update.
I’ve since run into a couple of other issues that are connected to using OpenSSH on Windows, especially in the context of a Jenkins CI system.
Accessing multiple git repositories via OpenSSH can cause problems on Windows
I’ve seen this a lot on a Jenkins system I administer.
When Jenkins is executing a longer-running git operation like a clone or large update, it can also check for updates on another project. During the check, you’ll suddenly see an “unrecognised host” message pop up on the console you’re running Jenkins from and it’s asking you to confirm the host fingerprint/key for the git server it uses all the time. What’s happening behind the scenes is that the first ssh process is locking .ssh/known_hosts and the second ssh process suddenly can’t check the host key due to the lock.
This problem occurs if you’re using OpenSSH on Windows to access your git server. PuTTY/Pageant is the recommended setup but I personally prefer using OpenSSH because if it is working, it’s seamless the same way it works on a Unix machine. OK, the real reason is that I tend to forget to start pageant and load its keys but we don’t need to talk about that here.
One workaround that is being suggested for this issue is to turn off the key check and make /dev/null “storage” for known_hosts. I don’t personally like that approach much as it feels wrong to me – why add security by insisting on using ssh as a transport and then turn off said security, which results in a somewhat performance challenged git on Windows with not much in the way of security?
Another workaround improves performance, gets rid of the parallel access issue and isn’t much less safe.
Use http/https transport for git on Windows
Yes, I know that git is “supposed” to use ssh, but using http/https access on Windows just works better. I’m using the two interchangeably even though my general preference would be to just use https. If you have to access the server over the public Internet and it contains confidential information, I’d probably still use ssh, but I’d also question why you’re not accessing it over a VPN tunnel. But I digress.
The big advantages of using http for git on Windows is that it works better than ssh simply by virtue of not being a “foreign object” in the world of Windows. There is also the bonus that clones and large updates tend to be faster even compared to a git installation with updated OpenSSH binaries. As an aside, when I tested the OpenSSH version that is shipped with git for Windows against PuTTY/Pageant, the speeds are roughly the same so you’ll be seeing the performance improvements no matter which ssh transport you use.
As a bonus, it also gets rid of the problematic race condition that is triggered by the locking of known_hosts.
It’s not all roses though as it’ll require some additional setup on behalf of your git admin. Especially if you use a tool like gitolite for access control, the fact that you end up with two paths in and out of your repository (ssh and http) means that you essentially have to manage two types of access control as the http transport needs its own set of access control. Even with the additional setup cost, in my experience offering both access methods is worth it if you’re dealing with repositories that are a few hundred megabytes in size or even gigabytes in size. It still takes a fair amount of time to shovel an large unbundled git repo across the wire this way, but you’ll be drinking less coffee while waiting for it to finish.