i3 window manager – a week later

A week ago I blogged about i3 window manager and my attempt to use it instead of MATE.  So, how am I am doing so far?

The long story short: I love i3.  It’s awesome.  But I still switch back to MATE once in a while.

What’s good about i3?  It’s super fast.  Even faster than a pretty fast MATE.  It’s keyboard navigated, and it only takes about a day to get used to enough keyboard shortcuts to feel comfortable and productive.  It’s super efficient.  Until I tried i3 I didn’t recognize how much time I spend moving windows around.  It is unexcusable amount of time spent needlessly.

What’s bad about i3?  It’s low level.  In order to make it work right with multiple screens, one need to get really familiar with xrandr, the tool I last used years ago.  If you are on a laptop, with a dynamic setup for the second screen (one monitor at the office, one at home, and an occasionally different project at client’s premises), you’ll need a bunch of helper scripts to assist you in quick change between these setups.

And then there is an issue of flickering desktop.  The web is full of questions about how to solve a variety of flickering issues when using i3.  The one that I see most often is the screen going black once in a while.  Sometimes it takes a second to come back, sometimes a few seconds, and sometimes and it doesn’t come back at all.  The more windows I have, spread across more workspaces, with more connected monitors – the more often I see the issues.  It’s annoying, and it’s difficult to troubleshoot or even report, as I haven’t found a pattern yet, or how to reproduce the problem.

With that said though, I am now about 80% time using i3.  I like the simplicity and efficiency of it.  It’s so good, that I work better even without a second monitor.  But when I do need a second monitor (paired programming, demos, etc), or when I have a projector connected, I switch to MATE.  That’s about 20% of my time.

i3 – tiling window manager

In the last few days my attention was unfairly distributed between a whole lot of tasks.  The fragmentation and constant context switching affected my productivity, so I briefly revisited my toolbox setup, in hopes to find something that I didn’t know about, forgot about, or have greatly underutilized.

One of the things that came (again) on my radar was terminal multiplexer tmux.  I’ve blogged about it before.  I used it for a while, but at some point, it faded away from my daily routine.  The two most useful features of tmux are:

  1. Persistent sessions, where you can work on a remote machine, detach your terminal, disconnect from the machine entirely, and then, at some point later, connect again and continue from where you left off.  With simpler workloads and reliable Internet connection, this became less useful to me.  When I do need this functionality, I use screen, which is more often installed on the machines that I work with.
  2. Terminal multiplexer, where you can split your terminal screen into a number of panels and work with each one like it’s a separate terminal.  This is still useful, but can be done by a number of different tools these days.  I use Terminator, which supports both horizontal and vertical screen split.  Terminology is another option from a choice of many.

I thought, let me find something that people who used tmux have moved on to.  That search led me, among other things, to “ditching tmux” thread on HackerNews, where in the comments a few people were talking about i3 tiling window manager.

Continue reading “i3 — tiling window manager”

Maintainers Don’t Scale

Daniel Vetter, one of the Linux kernel maintainers, shares some thoughts on why maintainers don’t scale, what it takes to do the job, what has changed recently and what needs to change in the future.

This reminded me of this infographic, which depicts a year (even though back in 2012 – probably much busier these days) for another kernel maintainer – Greg Kroah-Hartman.  Note that the number of emails does not include the messages on the Linux kernel mailing list (LKML), which is in its own category of busy:

The Linux kernel mailing list (LKML) is the main electronic mailing list for Linux kernel development, where the majority of the announcements, discussions, debates, and flame wars over the kernel take place. Many other mailing lists exist to discuss the different subsystems and ports of the Linux kernel, but LKML is the principal communication channel among Linux kernel developers. It is a very high-volume list, usually receiving about 1,000 messages each day, most of which are kernel code patches.

Mcrouter: a memcached protocol router

Mcrouter is an Open Source tool developed by Facebook for scaling up the memcached deployments:

Mcrouter is a memcached protocol router for scaling memcached (http://memcached.org/) deployments. It’s a core component of cache infrastructure at Facebook and Instagram where mcrouter handles almost 5 billion requests per second at peak.

Here is a good overview of some of the scenarios where Mcrouter is useful.  There’s more than one.  Here are some of the features to get you started:

  • Memcached ASCII protocol
  • Connection pooling
  • Multiple hashing schemes
  • Prefix routing
  • Replicated pools
  • Production traffic shadowing
  • Online reconfiguration
  • Flexible routing
  • Destination health monitoring/automatic failover
  • Cold cache warm up
  • Broadcast operations
  • Reliable delete stream
  • Multi-cluster support
  • Rich stats and debug commands
  • Quality of service
  • Large values
  • Multi-level caches
  • IPv6 support
  • SSL support

Amazon AWS : MTU for EC2

I came across this handy Amazon AWS manual for the maximum transfer unit (MTU) configuration for EC2 instances.  This is not something one needs every day, but, I’m sure, when I need it, I’ll otherwise be spending hours trying to find it.

The maximum transmission unit (MTU) of a network connection is the size, in bytes, of the largest permissible packet that can be passed over the connection. The larger the MTU of a connection, the more data that can be passed in a single packet. Ethernet packets consist of the frame, or the actual data you are sending, and the network overhead information that surrounds it.

Ethernet frames can come in different formats, and the most common format is the standard Ethernet v2 frame format. It supports 1500 MTU, which is the largest Ethernet packet size supported over most of the Internet. The maximum supported MTU for an instance depends on its instance type. All Amazon EC2 instance types support 1500 MTU, and many current instance sizes support 9001 MTU, or jumbo frames.

The document goes into the detail of how to set, check and troubleshoot MTU on the EC2 instances, which instance types support jumbo frames,  when you should and shouldn’t change the MTU, etc.

The following instances support jumbo frames:

  • Compute optimized: C3, C4, CC2
  • General purpose: M3, M4, T2
  • Accelerated computing: CG1, G2, P2
  • Memory optimized: CR1, R3, R4, X1
  • Storage optimized: D2, HI1, HS1, I2

As always, Julia Evans has got you covered on the basics of networking and the MTU.

The Most Mentioned Books On StackOverflow

Slashdot links to “The Most Mentioned Books On StackOverflow“.

How we did it:

  • We got database dump of all user-contributed content on the Stack Exchange network (can be downloaded here)
  • Extracted questions and answers made on stackoverflow
  • Found all amazon.com links and counted it
  • Created tag-based search for your convenience
  • Brought it to you

I’ve previously linked to a similar selection of “Top 29 books on Amazon from Hacker News comments“.

Things Every Hacker Once Knew

Eric Raymond goes over a few things every hacker once knew.

One fine day in January 2017 I was reminded of something I had half-noticed a few times over the previous decade. That is, younger hackers don’t know the bit structure of ASCII and the meaning of the odder control characters in it.

This is knowledge every fledgling hacker used to absorb through their pores. It’s nobody’s fault this changed; the obsolescence of hardware terminals and the near-obsolescence of the RS-232 protocol is what did it. Tools generate culture; sometimes, when a tool becomes obsolete, a bit of cultural commonality quietly evaporates. It can be difficult to notice that this has happened.

This document is a collection of facts about ASCII and related technologies, notably hardware terminals and RS-232 and modems. This is lore that was at one time near-universal and is no longer. It’s not likely to be directly useful today – until you trip over some piece of still-functioning technology where it’s relevant (like a GPS puck), or it makes sense of some old-fart war story. Even so, it’s good to know anyway, for cultural-literacy reasons.

The article goes over:

  • Hardware context
  • The strange afterlife of the outboard modem
  • 36-bit machines and the persistence of octal
  • RS232 and its discontents
  • UUCP, the forgotten pre-Internet
  • Terminal confusion
  • Key dates

Found via a couple of other interesting bits –
What we still use ASCII CR for today (on Unix) and
How Unix erases things when you type a backspace while entering text.

Immutable Infrastructure with AWS and Ansible

Immutable infrastructure is a very powerful concept that brings stability, efficiency, and fidelity to your applications through automation and the use of successful patterns from programming.  The general idea is that you never make changes to running infrastructure.  Instead, you ensure that all infrastructure is created through automation, and to make a change, you simply create a new version of the infrastructure, and destroy the old one.

“Immutable Infrastructure with AWS and Ansible” is a, so far, three part article series (part 1, part 2, part 3), that shows how to use Ansible to achieve an immutable infrastructure on the Amazon Web Services cloud solution.

It covers everything starting from the basic setup of the workstation to execute Ansible playbooks and all the way to AWS security (users, roles, security groups), deployment of resources, and auto-scaling.

10 things to avoid in Docker containers

10 things to avoid in Docker containers provides a handy reminder of what NOT to do when building Docker containers.  Read the full article for details and explanations.  For a brief summary, here are the 10 things:

  1. Don’t store data in containers
  2. Don’t ship your application in two pieces
  3. Don’t create large images
  4. Don’t use a single layer image
  5. Don’t create images from running containers
  6. Don’t use only the “latest” tag
  7. Don’t run more than one process in a single container
  8. Don’t store credentials in the image. Use environment variables
  9. Don’t run processes as a root user
  10. Don’t rely on IP addresses

Parsing text printouts within Ansible playbooks

I’m sure this will come handy soon, and I’ll be spending too much time trying to figure it out without this article: Parsing text printouts within Ansible playbooks.

It’s not every day that you see regular expression examples in the Ansible playbooks…