MATE + i3wm = Happy, happy, happy!

I finally freed up a few minutes to try this solution for combined MATE desktop environment with i3 window manager.  And I have to say it works perfectly!

I now have the best of both worlds – MATE’s out of the way desktop, with good multi-monitor support, and i3wm’s tiling windows and keyboard navigation.

Fedora 26 Update

Fedora 26 has been release about a month and a half ago.  But I didn’t have the time to update my laptop until today.  There was also nothing particularly exciting for me in this release, so there was no rush.

Here’s what I had to do today to update my laptop from Fedora 25 to Fedora 26:

# Let's get into root to save a few keystrokes
sudo su -
# Install all updates for Fedora 25
dnf update
# Install dnf system upgrade plugin
dnf install dnf-plugin-system-upgrade
# Download upgrade packages for Fedora 26
dnf system-upgrade download --refresh --releasever=26
# Reboot and install Fedora 26
dnf system-upgrade reboot

If you need more help, have a look at DNF system upgrade wiki page.

The whole process took less an hour, but your mileage may vary.  For me, the download itself was the slowest part.  I had to pull down about 2.5 GBytes worth of packages, and given my office connection, it took about 35-40 minutes.

The installation itself took about 10-15 minutes, for which, I think, the solid-state disk (SSD) helped a lot.

One more reboot later, everything was up and running.  Of all the changes pushed into this version, I think, the upgrade to PHP 7.1 is the one that affects me the most.

sshrc – bring your .bashrc, .vimrc, etc. with you when you ssh

sshrc looks like a handy tool, for those quick SSH sessions to machines, where you can’t setup your full environment for whatever reason (maybe a shared account or automated templating or restricted access).  Here’s a description from the project page:

sshrc works just like ssh, but it also sources the ~/.sshrc on your local computer after logging in remotely.

$ echo "echo welcome" >> ~/.sshrc
$ sshrc me@myserver

$ echo "alias ..='cd ..'" >> ~/.sshrc
$ sshrc me@myserver
$ type ..
.. is aliased to `cd ..'

You can use this to set environment variables, define functions, and run post-login commands. It’s that simple, and it won’t impact other users on the server – even if they use sshrc too. This makes sshrc very useful if you share a server with multiple users and can’t edit the server’s ~/.bashrc without affecting them, or if you have several servers that you don’t want to configure independently.

I’ve discovered it by accident when searching through packages in the Fedora repositories. So, yes, you can install it with yum/dnf.

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”

How Linux got to be Linux: Test driving 1993-2003 distros

Here’s a trip down the memory lane – “How Linux got to be Linux: Test driving 1993-2003 distros“.  The article looks at some of the early Linux distributions, remember what was already in and what came later.  Complete with screenshots.

I don’t remember for sure which versions of which distributions I used in the early days, but Slackware, Suse, RedHat and Mandrake were definitely among those.  Slackware was probably my first one, when I found the floppies in the only book on Linux at my college library.  Then, somehow, I found RedHat (I think 5.1 or so) in one of the local computer shops.  Later I tried Mandrake and Suse, cause those were laying around at work.  But RedHat stuck with me ever since.  I think I’ve used pretty much every version, including the move to Fedora, CentOS, and even the Red Hat Enterprise Linux, which we had the licenses for at some of my early work places.

Fun times!

HexChat IRC Client

Well, apparently I’ve been leaving under a rock for the last few years.  When it comes down to IRC clients, I’ve been mostly using XChat.  Turns out, XChat has been abandoned for years, and it’s still around mostly because Linux distributions care so much about it that they patch it and ship it.

As with anything in the Linux world, there are plenty of alternatives.  And one of them was right under my nose all these years – HexChat:

HexChat is an IRC client based on XChat, but unlike XChat it’s completely free for both Windows and Unix-like systems. Since XChat is open source, it’s perfectly legal.

HexChat is often shipped right next to where XChat is or used to be.  For Fedora users, it’s as close as “dnf install hexchat“.

Migrating to PHP 7

PHP 7.0.0 has been released for a year now.  I wasn’t in a rush to migrate to it, but with all the cool features and performance optimization, it’s definitely something I wanted to look into rather sooner than later.

It turns out that I’ve done my first PHP 7 migration a week ago, when I upgraded my laptop to Fedora 25.  Yup, that’s right.  It’s a bit embarrassing, but I have been developing on PHP 7 for a week without even noticing it.

$ php --version
PHP 7.0.13 (cli) (built: Nov 9 2016 07:29:28) ( NTS )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies
with Xdebug v2.4.1, Copyright (c) 2002-2016, by Derick Rethans

I think that was due to a few things:

  • It’s been quite a busy week, so my attention was all over the place.
  • PHP 7 backward compatibility is pretty awesome.  There are only a few things that need fixing in the older code bases, but if you haven’t been living under a rock for the last few years, you probably have nothing to change or worry about.
  • Most of the code I’m working on runs through TravisCI builds, which are executed on both PHP 5.6 and PHP 7.  Since we had this for a while now, most, if not all, of our code is PHP 7 compatible.

The absolute lack of any issues for the last week, related to this upgrade, is encouraging.  Now I will probably try to upgrade our servers sooner than later.

With that, I’ll go back to the wonderful and exciting world of PHP, leaving you to decide whether I’m very serious or very sarcastic…


EPEL : the effort behind the scenes

Catching up with recent news, I came across this blog post by Stephen John Smoogen in Fedora People, where he explains the reason for the recent disappearance of the Puppet package from the Extra Packages for Enterprise Linux (EPEL 6) repository:

This week various people using EPEL on RHEL and CentOS 6 have found that the puppet package is no longer provided by EPEL. The reason for this is due to the way EPEL packages are built and kept inside the repository. A package needs a sponsor so that we can hopefully get bug fixes and security updates to it. In the case of puppet this package is sponsored by the user kanarip. However, most packages aren’t whole pieces, they rely on other software.. in this case the package puppet relies on a lot of different ruby gems of which one of them was called ruby-shadow. This package was orphaned 30 weeks ago and while it did have other people watching it, none of them took over the package.


Last week a large cleanup was done to clean out orphaned packages from EPEL which removed ruby-shadow. Once that was removed, then all of the other packages depending on ruby-shadow were also removed. Today various people reinstalling systems found puppet wasn’t around and came onto #epel to ask.. which seems to have gotten the packages responsored and hopefully they will be back in the EPEL release in a day or so.

This problem has been happening a lot lately. I think it shows quite a few problems with how EPEL is set up and managed. For this, I take responsibility as I said I would try to clean it up after FOSDEM 2016 and it is still happening.

Unpleasant annoyance that shouldn’t have happened, right?  Well, yes, maybe.

Software is a complex matter, whether you are designing, developing, testing, or distributing it.  So things do go wrong sometimes.  And that was something I wanted to focus on for a second.

Forget the actual designing, developing, testing and documenting the software.  Forget all the infrastructure behind such a vital part of the Linux ecosystem as EPEL.  Just think of this single issue for a moment.  Once again:

A package needs a sponsor so that we can hopefully get bug fixes and security updates to it.

So what, I hear you say.  Well, let’s take a closer look.  EPEL provides packages for multiple versions of the distribution, hardware platforms and so on.  Let’s just look at the EPEL 6 for x86_64 (to keep things simple).  That looks like a lot of packages, doesn’t it?.  How many? At the time of this writing, from a random mirror that I got:

wget -q -O - | grep -c 'unknown.gif'

Yup. That’s 12,129 packages!  And each one of those has at least one developer behind it, to sponsor.  Some of those amazing people obviously maintain more than one package. Some packages are maintained by multiple people.  All of them are working hard behind the scenes for you and me to have an easy and stable access to a whole lot of software.  Here is a quote from the FAQ which is smoked and marinated in all that effort:

Software packages in EPEL are maintained on a voluntary basis. If you to want ensure that the packages you want remain available, get involved directly in the EPEL effort. More experienced maintainers help review your packages and you learn about packaging. If you can, get your packaging role included as part of your job description; EPEL has written a generic description that you can use as the basis for adding to a job description.

We do our best to make this a healthy project with many contributors who take care of the packages in the repository, and the repository as a whole, for all releases until RHEL closes support for the distribution version the packages were built for. That is ten years after release (currently) — a long time frame, and we know a lot can happen in ten years. Your participation is vital for the success of this project.

I don’t know about you, but for me, this is absolutely mind-blowing.  So I just wanted to take this opportunity to say thank you to all the brilliant people behind the scenes, who are often invisible, yet indispensable for the continuous success of Open Source software in general, and Linux in particular.

You guys rock!

Fedora 25

I’ve just upgraded my laptop to Fedora 25.  The upgrade process was a breeze (as per instructions from this article):

sudo su -
dnf upgrade --refresh
dnf install dnf-plugin-system-upgrade
dnf system-upgrade download --releasever=25
dnf system-upgrade reboot

About 2,500 packages (1 GB and some) were downloaded in about 40 minutes (yeah, our Internet connection could use a boost). Then rebooted and the upgraded kicked in. It took about another 40 minutes to run the process (I should get myself an SSD-based laptop next time).

The only thing I had to fix after the upgrade was the kmod-wl package, which provides the drivers for my wireless interface. Another reboot later all was good.

There were no major visual changes (I’m using MATE Desktop), but something felt a bit different.  After focusing on the differences for a few minutes, I think it’s the fonts.  Something is better, sharper, more polished.

Other than that, all is pretty much the same.  I’ll need to use it for a while to see if I can spot any changes.  Hopefully, at least a flickering issue that I got after some upgrade during the Fedora 24 life span is fixed now.  It was weird.  A particular application window would start to flick and refresh until clicked again.  Never figured out what it was. :)