Episode 5 – Ethics of Software Programmers

Today I discuss the implications of ethics in software development. We’ll take a look at some of my personal experience, and 2 new Netflix documentaries: The Social Dilemma, and Challenger: The Final Flight.

Episode 4 – Fall 2020 Programming Developments

A look at major new developments in the coding world for C/C++ – and some brief talk on Amazon BottleRocket and Microsoft’s Hyper-V advancements.

Episode 3 – To College or not to College?

For new and aspiring developers – in this episode I answer the #1 question asked from future coders – should I go to college? Pros and Cons of a college degree and the University system.

Contents: The Cold Truth of Job Seeking. Beware of For-Profit systems. Selecting a Degree. The actual meaning of a Computer Science degree.

Episode 2 – The Decline of Usenet

We return to the early 80s and 90s to discuss the rise of consumer access to Usenet and the following decline of the service and its rise to the ranks of the undead.

Contents:

  • Show introduction
  • Merging of networks
  • SPAM, SPAM, more SPAM
  • A brief analysis of the “Decline”

Resources:

Sources:

Credits:

  • Music by Audionautix.com – Creative Commons licensed music and commercial options available.

Blinkt! by Pimoroni

Searching for a way to carefully control illumination of a project, I discovered “Blinkt!” by Pimoroni. I was hoping for something that would easily connect to a Raspberry Pi 3 with a minimum of fuss.

The Blinkt! connects straight to the GPIO pins on the Raspberry Pi 3, and can also work on an extension board or off a ribbon cable. A warning: many cases have ‘ribbing’ along the side that will interfere with mounting the Blinkt! directly on the Pi – NONE of my cases were compatible without the ribbon cable.

Pimoroni provides an easy to use Python software library, which worked directly as advertised on Rasbian. The examples were easy to modify and get started. For my use-case, I wanted to create a flashlight with hue control. While these LEDs are very bright on there own, they don’t compare to a higher power utility light or flash light – understandable as they are being powered off the Pi. The array was surprisingly bright, but only just barely able to perform the functions I was hoping.

My goal was to provide carefully controlled lighting for creation of photographic inputs for a source project. The Blinkt! did it’s job fairly well:

One can find cheaper LEDs and ‘bigger setups’, but the simplicity and price are hard to beat for someone that’s searching for an item that’s get up and go. For this project, the $8 spent on this board was well worth it.

6/5/2003 Entry

GNU – the organization that keeps giving. I’ve currently got two different projects hosted on nongnu.org. All things given, it’s a lot better service than sourceforge. (Ahhh, sourceforge, home of twelve million dead projects, and a couple dozen of still useful ones.) But that’s not what I’m here to write about.

I’m here to write about the sickening pothole into hell that is autoconf. Autoconf, through some sickening joke, has managed to succeed as the #1 method of building makefiles. It’s used by all major projects, in some form or another. If it’s on GNU/Linux, it’s most likely configured by autoconf(unless we’re talking about X11, the only piece of software that makes autoconf look stylish.) But see, the funny thing is, I don’t think ANYONE quiet understands how Autoconf works outside of the three or four people that maintain it.

I would like to know for instance, why on half the projects I compile, after running configure once, and typing make, configure, for no apparent reason decides that it needs to run AGAIN. Each time running the SAME freaking tests OVER AND OVER AND OVER. I can go through half of them by memory now, from watching compile screen after compile screen after compile screen. Let me think “checking for unistd.h”, “checking whether build environment is sane”, “checking for BSD-compatible install”, and so on and so forth. One wonders if it ever occured to anyone that *maybe* this invention of a hard drive could *somehow* manage to actually store this information for later use.

But, I digress. It’s the very height of fun when installing program xyz-version 5.4.2, to sit and run through the 55,000 different options for this program. Is it –with-x today? Or –with-gtk? Or do I need to do a –enable-gnome? Oh the choices!

Of course, when things go wrong, that’s where the real fun begins. Oh no, the xyz-version 5.4.2 thinks that I have libabc installed in /usr/lib, when it’s really in /opt/kill/me/now/damn/it. Of course, the wonderful configure picked up on the fact that it exists, just not WHERE it exists. I don’t, however, know this immediately. Instead, I have to recompile the program, and redirect stderr(hint for n00bs its >&) to a file, tab through the file, and find the start of a 93 line long list of errors.

Now, if you where in this situation 5 years ago, you would know to take a quick look at the Makefile, and add a few more flags to one environment variable or another. So, you, being the seasoned Unix person you are, first go and pop up emacs(the one thing the GNU people got right), and open the Makefile, only to be suprised with a 50,000 line long monstrosity, with multiple, conflicting environment variables. Upon seeing this gateway to the seventh circle of hell,you of course, do one of the following: A. close the editor and try another piece of software, B. try to edit one of the 53 different .in, .am, .figtree, .bannana, .yoyo files that auto* uses, or C. shoot yourself in the head with a twelve gauge shotgun. Or, you could try to wade through the file, editing the 500 different $LIBS flags, all of which are completely useless except for the one three directories down called $(FOO_BAR_NONSENSE_NAME_VARIABLE), only to discover that having found the proper variable, FINALLY, running make this next time causes “configure” to rerun and trash all that hard work. Of course, you forgot to write down the file/line number or name of the variable, so you start the wonderful search all over again.

Let’s be honest. People don’t write configure.in files, they either A. use a tool to generate it, or B. copy them from someone else. What else would explain the same five errors that happen in all the programs that use autoconf. Finding documentation is even more of a challenge, you are left either purchasing a book(which will be out of date), reading an ancient howto(most of which doesn’t work properly), or wading through the even more wondrous “info” tree. It doesn’t help matters that the “info” tree seperates things out into 4 different packages, requiring you to flip from one to the other, to figure out why your configure.in is causing your makefile.am to puke when run through automake.

I’ve come to the conclusion that the auto* tools where designed by Satan himself in an attempt to drive me into a slow and deliberate madness. The sad thing is, I think it worked.