X11 Must DIE

Unix, C, computing like it's 1980.

Perhaps a vacation is in order.

For what it’s worth, I thought I’d explain the long absence of regular posts.

I’ve recently been working about 60 hours a week.  I work in an IT/Engineering field, and when I get done, the last thing that I want to do is sit down in front of a computer and play with software or discuss it.  I have gotten into the habit of simply getting done with my work and when I get home, I’ll go to the gym, go fishing, or pretty much anything that doesn’t involve computers.

So, if there are long breaks in reviews or discussions, suffice it to say…I am probably just doing something else. 🙂

Cool toy: binary-clock


Pictured running lower right.

I take it on assumption that if you read my blog, you’re probably familiar with Kmandla’s current one, but assuming that this one slipped under your personal radar, I thought I’d share it as just a fun little ncurses program to spice up your desktop.

Source is at https://github.com/JohnAnthony/binary-clock and it requires only libs you’ve probably already got if you build curses programs at all.  Easy to make, easy to run.  It keeps time, in binary.  What’s not to love?

Beyond that, the author added a suggestion that if you find the program useful, then please donate to www.meningitisuk.org or your local meningitis charity.  Perhaps we should all consider not only donating, but adding short lines about worthwhile charities to FOSS program documents to help raise funds for things that really do matter.

The Case for Simplicity


 In our monthly meeting (this almost implies some kind of professionalism that doesn’t actually exist) at the linuxbbq irc, the subject of obfuscation came up.  While we’ve often discussed avoiding brittle algorithms just to catch edge cases, the flip to this would be that any implementation (ANY of them) should be easy enough to understand that the users who would fall under ‘edge case’ should be able to figure out how to modify things to suit their needs.

I’ve seen simple programs written to be confusing and complex programs written to be easily understood.  The latter of which should honestly be the goal of any programmer.  I cannot even begin to stress how important being clear and concise is.  While it makes troubleshooting your own work easier, it also helps anyone who might have a project based on similar concepts, those who fork your project for their own purposes, and even for people who are just looking to understand how something works.  A well written example can often be more educational than an explanation.

James spoke about the usefulness of well placed white-space and commenting, and how breaking things up into digestible portions makes it easier on someone to make sense of even if they are unfamiliar with the language.  For FOSS projects that are written to be simple, this can allow the user to not only use but modify your work to fit their particular purpose.  I personally believe that this allows a project to grow organically to fill needs.

I simply don’t understand why someone would not look for the simplest way to present a concept.  It’s also worth mentioning that shorter isn’t always simpler.  It’s better to be verbose without adding layers of abstraction if at all possible.  If I’m missing some advantage to making code hard to understand, then please share it with me.  Until such time as a good reason for making things more complex than they should be is presented to me, then I will make it a personal goal to make sure that anything I do is easy to understand and modify.

Unix Koan that Pidsley suggested. 🙂

Always be useful


One of the great joys of the internet is that no matter how obscure of an interest you have, there is normally a simple way to find people who likely share it.  What was once relegated to obscure books can now have a bbs and irc channel dedicated to them.  People from all over the world can learn from the collective experience of their peers, and share their own experiences with subjects that most people you may contact on a regular basis will not have even heard of.  It’s wonderful!

….except, when it isn’t.

With every group, regardless of how small or obscure, there is now an almost learned behavior to lean into elitism and polarized discussion.  I’ve read commentary on how this has developed over the last few years, but rather than quoting papers about the emergence of trolls (internet, not mythological), allow me to simply make a few short suggestions on how to keep criticism as productive as possible when it comes to the FOSS world.

1). All criticism should be centered around a need for improvement.  There is absolutely no benefit to having a huge discussion that revolves around an issue that doesn’t stand to improve on a project.  I would compare this to the overweight boxing fan who insults a fighter’s style, without the least bit of experience in the ring themselves.  If it’s a discussion for the sake of discussion, it will probably be avoided by the people who are actually working on making the project better.

2). If possible, provide both reasons and a working example to a potential change.  Let’s say that you’re looking over someone else’s script.  Saying “You use too many pipes” is not nearly as beneficial as “Here is how I would do the same thing <insert example>.  Doing this cuts the pipelines in half, which reduces resource usage significantly.”  If you can’t improve on the original, then most of the time your input would be better placed in bug tracking.

3). Context is important.  Some things that are shared are simply “Jumping off points” for ideas.  Not everything is a polished or finished product, and this is especially true for many bbs or irc examples.  Criticizing the formatting of something that starts with “Well, this is a pretty cool way to solve ____ issue,” is most certainly a waste of your time and the author’s, and everyone who will subsequently read it.  While you may get the satisfaction of patting yourself on the back for having such amazing syntax skills, it’s very possible that you’re just being a nuisance.  When it comes to a finished product, then you can and should make pull requests to the source tree over these subjects.  At this point, it isn’t criticism at all, but simply sharing the workload of the project for a better outcome.  The context in which the subject is brought up is the difference, and make sure that any criticism is in line with the subject’s goals.

4). Action is always more important than criticism.  This ties in with the example above, but it’s important to keep perspective on who it is that is doing the work.  Many authors and testers are doing whatever they can using their own time to provide free solutions to the public, and are not personally benefiting from their efforts at all.  While constructive criticism can be a good thing if directed correctly, it is hugely beneficial to take some of the load for implementing changes onto yourself.

5). Debate is a last result, and probably signals the end of any kind of possible benefit.  In all of the actionable cases, there is always the possibility that the author’s goals won’t align with yours.  This happens.  If you’ve provided reasons for change and workable changes, and the other side of the discussion is still adamantly opposed to them, then you can always fork the project to implement changes on your own branch.  The natural selection of code then becomes the defining factor on who was right.  Keep in mind that this may also mean that you will be providing support on the branch, implementing bugfixes, and generally maintaining a project.  If this is out of the question, then perhaps it’s best to make your point and move on.  Extended arguments very rarely change anyone’s mind, and simply serve as background noise to an otherwise productive project.

While I’m sure this doesn’t cover all aspects of criticism, I think that simply being really mindful of who is working on what project will generally be helpful to everyone who is out to provide genuine help.  To those who are out to criticize others just for the sake of being a critic, find a new hobby. 🙂

cli Kung-fu


“I fear not the man who has practiced 10,000 kicks once, but I fear the man who has practiced one kick 10,000 times.” – Bruce Lee

Every month or so, I’ll run across a need that I end up discovering is best served by some very simple tool that has been sitting around on my system without me truly understanding how to use it.  GNUcoreutils on a Linux system are probably the most common of these, and while I appreciate the learning process, this normally starts me down the long track of “So, just how much do I NOT know?”  The answer is that the more I learn, the more I realize that I fail to fully understand.

That bit of humble-pie aside, I am at least made more aware of what all CAN be done without the need for many additional tools to a native cli/tui environment.  This leads me to think about how much could be accomplished if I simply knew all of the tools and options for the most basic tools in the GNUcoreutils toolkit.  Really, the entirety of the Unix way is found not in the use of complex tools, but in mastering the simple ones and learning to chain them together in an elegant arrangement.  The beauty of any unix or unix-like system is in piping and shell, the power to control stdin/out/err and bend them to our wills.  So often we simply are out to reinvent the wheel simply because we failed to see that there was already a cart built that could fill our needs if only we knew how to make it work for us.

So, dear cli kung-fu masters in training, allow me to pose a challenge for those of you who wish to reach enlightenment on the path to the Unix-way.  Go to http://www.gnu.org/software/coreutils/manual/coreutils.html, and pick one tool.  Learn every single option and switch available for it, and play with options using it until you truly understand the depth of what is being offered.  I can almost assure you that you will learn something that you didn’t know previously, even if you’ve used the tool before.  I personally have found that with the use of pipes and tricks that I already know with stream editing, that I come up with new and different ways to do things.  These aren’t always “better” than how I might have done them otherwise, but nonetheless, I find my own knowledge increases with every new trick I learn.  While whatever I’m doing may not be the perfect scenario to need the new method, you can be assured that it will probably be exactly the method that you’ll need in some situation.

The master of cli is not the man who knows how to use 10,000 programs, but who can handle 10,000 cases with a single tool.

tech_worldview == clarity;


David said my pic was broke…this is probably more enjoyable anyhow.

If you spend any amount of time in any kind of open discussion regarding *nix or BSD type systems, you’re bound to run across *gasp* people with strong opinions.  For the most part, I don’t participate in things that don’t directly affect me or that don’t fit my particular ‘tech worldview’.  I would say that easily 98% of the strongly voiced opinions are due to either Parkinson’s Law of Triviality or Sayre’s Law, however you want to view it.  I’m sure that the term “bikeshedding” is nothing new to my BSD brothers and sisters, but there are a few points that I personally use subconsciously that will ultimately determine my views on any subject.

Simple > Complex

Given the option between 2 choices, the quickest and simplest implementation will be my generally preferred option.  Everything about most of the software that I use reflects this.  sc is a great example.  I don’t need libre office if all I’m doing is making a few numbers automatically have some arbitrary math done to them when I make changes to some other number.

Functional > Form

I USE software for a specific purpose, pretty much every time.  I’d much rather have a predictable piece of software that works than a beautifully constructed piece of art that doesn’t do what I need out of it.  When there is the possibility of making something both functional and nice to look upon, then that’s going to be my choice.

Semantics > Syntax

This is the one where I guess I must differ from a lot of people.  I have more respect for creative and useful programs (and their programmers) than a someone who makes a well-constructed house of uselessness.  I’m not saying that obfuscation is good, not by any means.  Rather, it annoys me to no end when someone shares something that they’ve done that is a proof-of-concept or neat tool they’ve made, and then the first response is in regards to the format in which it was written.  Creativity in programming is the big hurdle, and that’s where I’d personally like to see more emphasis.  I assure you, there will be no lack of time for people to fix your indentation, and there will be no lack of volunteers if the project is actually worth having.

Context Matters

While I’m all about doing the most with the least, it would be totally unreasonable for me to expect someone who is working on projects with webgl to be using links2 or w3m.  ed is so inefficient for me that it would grind my work to a screeching halt.  Obviously, it can be used for huge projects, but it’s not worth the effort to swap to something I find drastically harder to deal with just for the sake of “being minimal.”

So, when the discussion inevitably swings around to “What’s your thought on ____ init?”  I will either go on a horrible rampage about how sick I am of this particular topic, or I’ll look at the things that I consider my few clear points and ask the great question: “Does it init?

emacs-lisp quick-hacks



…that’s just cool.


As I’ve mentioned previously, and will probably do so again, I am an avid (rabid) emacs user.  When I’m setting up a new *nix system, it will be one of the first things that I put on, as I am accustomed to using it.  That being said, despite having all of the fantastically complex init files and loadable foobar.el options that I may have, some times I end up saying, “You know, it sure would be cool if I didn’t have to repeat this same action over and over.”

Let’s use a metaphorical situation that might warrant this.  Let’s assume we’re looking over and proofreading someone else’s poorly written C coding (as opposed to my own poorly written C), and I want to call attention politely to certain lines in a commit.  I’d like for it to always appear as a properly commented code function, be tied to a single button press (we’re assuming that this will need to be repeated quite often), and return the cursor to the previous position.  I’m going to go out on a limb and assume this isn’t the kind of action that we’ll be performing so often that it needs to be a permanent function, so rather than put it in our init, we can simply pop over to a *scratch* buffer, write out something short to make…oh, let’s use “F12″…print out our friendly comment, and then evaluate it for use in only this session.

(defun whattheflip ()
 "make automatic comment"
    (goto-char (line-end-position)) 
    (insert "\n /*^^^wtf is this? It's horrible!!!*/ \n")
(global-set-key [f12] 'whattheflip)

Now, a couple of C^j’s later, we can flip back over to the code we’re proofreading and every time we press our F12 button, we get an automatic comment inserted on the next line that should hopefully serve as a friendly notice to our beloved teammate that we aren’t 100% clear as to why they’ve chosen to do something in a particular manner.

While this exact use may not perfectly suit your needs, I’ve often found that it’s the ideas that serve us better than the exact application.  For those interested in other cool hacks, I’d at least check out http://ergoemacs.org/emacs/elisp.html for other quick uses for emacs-lisp in text processing.

With enough shell, everything is automatic


…sid test system x86_64, 257MB of updates behind…

I guess I’ll write something while I wait to see what broke.

While I am by no means a fantastic shell/bash script writer, I will readily admit that I spend a good deal of time playing with creative use of shell scripting.  Scripting in general has been the biggest blessing and curse of my life in userland.  I’ll also readily admit that 90% of the time, I use it to shortcut things that I do on a regular basis.  “Man, instead of me having to set up a 2nd workspace and open the same 3 programs I’m always using in tmux…I could totally make a script for that.”  I would say that this is the lazy man’s path, but I’ve yet to quantify the amount of time saved over the amount of time it takes me to write them.  Could be I’m adding extra work, but that’s not really the point anyhow.

When it starts to get cool is when these little scripts start growing.  “Well, I’d like for this pane to be links2, unless I’ve failed to set up an internet connection, in which case…it should open a second workspace with ceni opened.”  30 minutes later, I’ve now saved no time at all but have managed to run a short ping test to determine which of the two paths should be followed.

Essentially, this is ‘bloat’.  This is MY bloat, though, and I certainly am not forcing it upon anyone else.  I have tons of emacs-lisp bloat too, but it’s all designed to accommodate MY use.  Saving a few hundred keystrokes and possible RSI (emacs and vim users can both laugh here) over the course of my regular use.

As my understanding of shell scripting improves, I find that there is practically no end to how much control the user has over their system with creative use of shell.  I don’t know that it’s necessary, and I’m not interested in debating the merits of one form of scripting over another.  What I would suggest, is that if you’ve failed to do so, write a script that would be useless to anyone except you.  Assuming that you use a floating wm in X, then write one that opens a series of frames with your favorite programs open in them using perfectly balanced geometry.  If you use a terminal multiplexer, then write a script to lay out your most common working environment.  The point is not the specifics, but rather that once you start to use it, that you’ll begin to have little creative ideas about how you could make it slightly more efficient (or, at least I have these thoughts, and so I assume everyone else will.)

As you begin to implement little tweaks, you’ll run into snags and setbacks where things don’t work “quite” like you meant for them to.  This is expected, and in the end, while your application of scripting may not be useful…your ability to control variables on your own personal system and to troubleshoot will drastically improve.  I’m sure there are scripting pros out there that don’t need any of this, and that’s cool…you guys just keep doing what you do.  For the rest of us, practice leads to consistent improvement.

Libs worth playing with: Curses


vim and xserver, what happened?

In the early days of BSD Unix, there was a game called ‘rogue’ and it utilized some very interesting screen handling on terminals.  A few layers of abstraction later, this grew into what we now call “CURSES.”  Essentially, CURSES is an application programming interface that allows geometric location of text and lines to be passed to a terminal or terminal emulator.  In more anecdotal words, it’s the simplest of ways to make menus and windows and put them where you want them.

I’d list CURSES/NCURSES programs, but…well, there are literally thousands of them still in use.  w3m, GNU screen, tmux, midnight commander, most text editors for terminal, etc.  I’ve used some variant of the CURSES interface to write many little handler programs for which I felt that a TUI was the best possible solution, including a silly Monty Python based project written in PyCURSES, that just so happened to be a fun implementation of of a rogue-like.  It was a total blast to work on, and despite being horribly easy to beat, was a good exercise for experiencing the capacities of OOP that can be used in python in an enjoyable manner.

class EvilKillerRabbit:

Whatever comes next has to be awesome!

All of this is really just a minor bit of backstory that leads to me saying that if you haven’t yet tried it out, curses can often provide some useful utility for making your program easier to deal with while maintaining really good cross-system compatibility.  Where do you start?  Well, here’s a few of the places that I grabbed my earlier info from:

Writing Programs in CURSES

NCURSES Programming HOW_TO

…and those should lead to all kinds of new information that will organicially expand your personal understanding of what may still be one of my favorite standards for graphics in your programming.

As Repetition becomes Rhetoric



I do not recall where the above picture came from, but I had it saved locally to my HDD.  It has nothing to do with this article, but if someone reading this says “Hey, that’s my desktop!” please send me your name and some way for me to credit your for the joy that you brought to me.  I may even throw in a cooler pad for that netbook, as you’re my personal hero.

Even within the little niches of computing, a lot of buzz words are thrown around and honestly it bothers me as they’re not always factual or even well informed.  Perhaps it’s due to a counter-culture to the direction that technology is currently heading, but I often wonder if some of the contempt being thrown around is simply ill-will for the sake of trying to be an elitist niche group.

For example, if you frequent any forum or irc channel regarding the Unix-like operating systems, someone is almost certain to throw out the phrase “Microshaft Wangblows” (or some derivative statement.)  This gets my blood boiling, simply because while it may not suit all of my needs, there is someone out there that is obviously much happier with it than they would be with an alternate setup.  The implication is that due to it being MS Windows, that it is somehow inferior in every single aspect to whatever system the creative wordsmith above has chosen to use.

Now, there are certainly aspects of any Microsoft product I’d like to see changed.  I’d like them to be full open-source under a BSD or MIT license.  I’d also like someone to tell me they bought me a lovely island in the Caribbean to live on, with a full staff of paid servants.  The latter is more likely.  I’d like for the support in proprietary binary drivers for Windows to be made available for developers of open-source drivers.  I’d like to see a more clear and concise file system structure.

Still, for a great many people, the design used is so ingrained in people who are well served by it that it is the best system for them to use.  My mother-in-law, for instance, really should not be trying to use BSD.  Once, I set her up a nice partition which was nothing more than a web-kiosk using Chromium, XFCE Panel, and a front-end for wickd.  While not my personal choices, it made good sense to me to not try to leave the point-and-click interface she had become accustomed to.  After a few attempts at using it for even the most basic of things for most Unix-like OS users, I decided that she was by far best served by never changing anything.  (It’s possible that by moving her start menu to a new-location on the desktop, you would render the entire system useless and need to fly 1400 miles to put it back.)

I’m certainly not saying that there aren’t things that should be changed, and even I might be guilty of raging about many of the automated processes that I have minimal control over in most mainstream operating systems.  I am simply urging people to use a well thought out criticism rather than simply spewing hate towards any particular setup.  Each of them come up short in some aspect, and only by having a clear objective can we hope that there will ever be any improvement.