If you have a lot of Droplets on your account, you probably agree that it's hard to keep track of all of them—especially if you create new ones and destroy them frequently for one-off workloads. A common pain point is having to look up a Droplet's IP address when needing to SSH into it.

I created do-ssh-alias to help address that. Let's look at how it can help.

What is do-ssh-alias?

Let's assume you have a Droplet named shiny-blog. Usually you would look up its IP address and then SSH into it like so:

ssh username@1.2.3.4  

What if, instead, you could simply run the following command?

ssh shiny-blog  

This is where do-ssh-alias comes in. It creates SSH aliases for all your Droplets at once so you can easily SSH in, without having to worry about what user or hostname to use.

It is especially useful if your Droplets' hostnames are FQDNs (e.g. shiny.example.com) that don't point directly to the Droplets' IP addresses. One example is using Cloudflare in front of your website, so your domain name resolves to a Cloudflare server instead of your Droplet.

How do I use it?

do-ssh-alias depends on the programs jq and doctl. The first step is installing jq and installing doctl. Linked are the installation instructions for each program. Once you install doctl, log it in to your DigitalOcean account.

With the dependencies taken care of, let's now install do-ssh-alias. You can either download the script from GitHub or use the command line:

wget https://do.co/do-ssh-alias  

It's always a good idea to review any scripts you download from the internet before executing them.

Once you have the file on your computer, update its permissions to allow it to be executed:

chmod +x do-ssh-alias  

It's now ready to use. To generate aliases for your Droplets, run:

./do-ssh-alias > ~/.ssh/do_aliases

This will run do-ssh-alias and save the results in the file ~/.ssh/do_aliases.

Finally, update your ssh config to actually use the file with the aliases. Open ~/.ssh/config in a text editor and add the following line at the top:

Include do_aliases  

That's it. You can now SSH to your Droplets using their hostnames! Any time you create or remove Droplets, simply run it again to update the configuration.

What else can it do?

do-ssh-alias only generates SSH aliases, but it accepts a few options for some flexibility:

• -u: Pass your SSH username like -u sammy to automatically use it for all hosts.
• -i: To ignore certain Droplets and not create aliases for them, pass their hostnames like -i ignored-hostname-1 -i ignored-hostname-2.
• -s: Pass a suffix with the -s option to generate additional aliases with that suffix stripped. For example, if your Droplet's hostname is shiny.example.com passing -s .example.com will generate an alias for ssh shiny in addition to ssh shiny.example.com.

Below is an example of using all three options.

Show me an example, please!

Let's assume you have the following Droplets on your account:

• droplet1
• droplet2.domain.com
• droplet3.domain.com

Running:

do-ssh-alias -u sammy -i droplet1 -s .domain.com  

will generate aliases for:

• ssh droplet2.domain.com
• ssh droplet2
• ssh droplet3.domain.com
• ssh droplet3

all using the username sammy to log in. The SSH config will look like so:

Host droplet2.domain.com droplet2  
    Hostname Droplet2-IP
    User sammy

Host droplet3.domain.com droplet3  
    Hostname Droplet3-IP
    User sammy

Resources

Here are some resources you may find useful:

• do-ssh-alias on GitHub
• How To Configure Custom Connection Options for your SSH Client

Note: doctl itself provides similar functionality through the doctl compute ssh command which allows you to SSH into a Droplet using its ID or name. The main difference is that doctl looks up the Droplet's IP address using the DigitalOcean API every time you run it, while do-ssh-alias generates a static config file that ssh reads. You might prefer do-ssh-alias if:

• you want an SSH config that can be copied to other computers without having to install doctl or store your API token on them; or
• want to avoid the added latency of doctl's API request.

Programming time, dates, timezones, recurring events, leap seconds... Everything is pretty terrible. The common refrain in the industry is Just use UTC! Just use UTC! And that's correct... Sort of. But if you're stuck building software that deals with time, there's so much more to consider. It's time... To talk about time.

This is one of the best articles - experiences? - I've ever read. It's funny, well-written, deeply informative, and covers everything from programming with time, to time and UI design, to time and accessibility. This is simply an amazing piece of work.

Within a few days, the General Data Protection Regulation (GDPR) will take effect. Hiawatha collects and stores the visitor's IP addresses. Since an IP address is personal data, it's possible that you must comply to the GDPR for that. One of the first things you must to is to determine the lawfulness of the processing. Recital 49 of the GDPR states that ensuring network and information security constitutes a legitimate interest, as defined in article 6 (1) lit f.

So, in normal English, you are allowed to store the IP address of a visitor for the purpose of securing your webserver. However, you still have to comply with the rest of the GDPR. That means that you should not keep IP addresses for longer that necessary (use logfile rotation), secure the logfiles well, be clear to your visitors what information your collect, for what reason and how you keep that information (privacy policy on your website) and stick to that.

The visitor, or the data subject to speak in legal terms, has the right to see what information about him/her is being processed. Of course, that person has to prove that he/she is indeed the owner/user of that IP address and also for what period of time. Otherwise, you have a data breach. That it's very hard or even practically impossible to prove that, is not your problem.

It’s easy to make plausible that the information in the system, exploit and garbage logfile is necessary for information security. It might be a bit more tricky for the information in the access and error logfile. You can use Hiawatha’s AnonymizeIP option to deal with that. The manual contains an error. It says that it also anonymizes IP's sent to the Hiawatha Monitor, but the Monitor doesn't collect IP addresses. It used to do so in an earlier version, but I forgot to remove that remark from the manual.

After reading all this, you may ask yourself: do I really need to go through all this hustle for just a personal website? No, article 2 (2) lit c clearly states that the GDPR does not apply to the processing of personal information in the course of a purely personal activity.

The single biggest misconception about iOS is that it’s good digital hygiene to force quit apps that you aren’t using. The idea is that apps in the background are locking up unnecessary RAM and consuming unnecessary CPU cycles, thus hurting performance and wasting battery life.

That’s not how iOS works. The iOS system is designed so that none of the above justifications for force quitting are true. Apps in the background are effectively “frozen”, severely limiting what they can do in the background and freeing up the RAM they were using. iOS is really, really good at this. It is so good at this that unfreezing a frozen app takes up way less CPU (and energy) than relaunching an app that had been force quit. Not only does force quitting your apps not help, it actually hurts. Your battery life will be worse and it will take much longer to switch apps if you force quit apps in the background.

Here’s a short and sweet answer from Craig Federighi, in response to an email from a customer asking if he force quits apps and whether doing so preserves battery life: “No and no.”

Here, from the official support document on forcing applications to close, is Apple’s own advice on when to use this feature:

When you double-click the Home button, your recently used apps appear. The apps aren’t open, but they’re in standby mode to help you navigate and multitask. You should force an app to close only when it’s unresponsive.

Update: MacDailyNews quotes a 2010 email from Steve Jobs:

Just use [iOS multitasking] as designed, and you’ll be happy. No need to ever quit apps.

Just in case you don’t believe Apple’s senior vice president for software, Apple’s own official support documentation, or Steve Jobs, here are some other articles pointing out how this habit is actually detrimental to iPhone battery life:

• Fraser Speirs (back in 2012!): “Misconceptions About iOS Multitasking”
• Thorin Klosowski: “Quitting All Your Apps in iOS Can Actually Worsen Battery Life”
• Kendall Baker: “Stop Force Quitting Your iPhone Apps”
• The Wirecutter: “What You Should (and Shouldn’t) Do to Extend Your Phone’s Battery Life”
• Kyle Richter: “The Force Quit Fallacy”

This thing about force quitting apps in the background is such a pernicious myth that I’ve heard numerous stories from DF readers about Apple Store Genius Bar staff recommending it to customers. Those “geniuses” are anything but geniuses.

It occurs to me that one of the best examples proving that this notion is wrong (at least in terms of performance) are YouTube “speed test” benchmarks. There’s an entire genre of YouTube videos devoted to benchmarking new phones by running them through a series of apps and CPU-intensive tasks repeatedly, going through the loop twice. Once from a cold boot and the second time immediately after the first first loop. Here’s a perfect example, pitting a Samsung Galaxy S8 against an iPhone 7 Plus. Note that no apps are manually force quit on either device. The iPhone easily wins on the first loop, but where the iPhone really shines is on the second loop. The S8 has to relaunch all (or at least almost all) of the apps, because Android has forced them to quit while in the background to reclaim the RAM they were using. On the iPhone, all (or nearly all) of the apps re-animate almost instantly.

In fact, apps frozen in the background on iOS unfreeze so quickly that I think it actually helps perpetuate the myth that you should force quit them: if you’re worried that background apps are draining your battery and you see how quickly they load from the background, it’s a reasonable assumption to believe that they never stopped running. But they do. They really do get frozen, the RAM they were using really does get reclaimed by the system, and they really do unfreeze and come back to life that quickly.¹

An awful lot of very hard work went into making iOS work like this. It’s a huge technical advantage that iOS holds over Android. And every iPhone user in the world who habitually force quits background apps manually is wasting all of the effort that went into this while simultaneously wasting their own device’s battery life and making everything slower for themselves.

This pernicious myth is longstanding and seemingly will not die. I wrote about at length back in 2012:

Like with any voodoo, there are die-hard believers. I’m quite certain that I am going to receive email from people who will swear up-and-down that emptying this list of used applications every hour or so keeps their iPhone running better than it would otherwise. Nonsense.

As Fraser mentions, yes, there are exceptional situations where an app with background privileges can get stuck, and you need to kill that app. The argument here is not that you should never have to kill any app using the multitasking switcher — the argument is that you don’t need to do it on a regular basis, and you’re not making anything “better” by clearing the list. Shame on the “geniuses” who are peddling this advice.

And don’t even get me started on people who completely power down their iPhones while putting them back into their pockets or purses.

This week, Mozilla announced Firefox 54, which provides multi-processing capabilities for "remarkably" improved performance and memory usage.

The post Mozilla Delivers “the Best Firefox Ever” appeared first on Thurrott.com.

I’m pleased to say that Relayd and Httpd Mastery is now available in print and ebook.

Sponsors should be able to log into their accounts and download the updated book.

I don’t have a print copy of the book in my hands yet, but they’re on the way. Unless something goes wrong, I’ll a) have copies mailed to all the print sponsors before I leave for BSDCan, and b) have a few copies for BSDCan.

Now to put in some quantity time for the third edition of Absolute FreeBSD before BSDCan…