installing pop!_os 21.10 on a minis forum um250

Today I pulled the Windows 10 Pro out of my UM250 computer and installed Pop!_OS 21.10. I’d ordered a 1T WD Blue 3D NAND SATA M.2 2280 (WDS100T2B0B) drive to replace the original existing Kingston 512 GB drive on which Windows 10 Pro came preinstalled. The 1T drive was cheap enough at around US$90 from Amazon; Amazon and Western Digital were running a special at the time. And I’d been wanting to do this ever since Microsoft through a Windows 10 update started to nag me about running Microsoft Edge in place of my other browsers of choice, among other annoyances. Microsoft had worn out its welcome with me yet again.

I downloaded the Pop!_OS image from System76 ( ) and flashed an old 8GB USB drive. This is definitely old had; there are more than enough tutorials on how to do this, so check elsewhere. After switching the two SSDs, I powered up the UM250 which almost immediately dropped me into the BIOS configuration screens. I tabbed over to the Boot section, and made sure to change the boot protocol from just UEFI to UEFI&Legacy, then saved the change. I plugged my 8GB USB drive into one of the two USB ports on the UM250’s front panel and then reset the UM250. The next boot was into Pop!_OS on the thumb drive. From that point I proceeded to install Pop!_OS.

It took about ten minutes to get the base system installed, then another ten or so minutes for me to tweak a few things to my liking. I’ve just gotten started but I already like the environment a whole lot better than Windows 10. More than likely I’ll need to go back into Windows 10 to pick up some development projects I was working on, but these are written in languages and with tools that are portable across operating systems. The only thing that won’t run on Pop!_OS are Microsoft Visual Studio projects (obviously). I don’t care. If I did care I wouldn’t have switched away from Windows 10.

I picked Pop!_OS primarily because it’s Ubuntu derived. I also picked it because it’s beating back the really bad bits of Gnome 4. I would have preferred to install Fedora 35 primarily because of Fedora’s up-to-date tooling, but I installed Fedora 35 on my big MBP as a Parallels VM and I came to intensely dislike their Gnome desktop. Pop!_OS has reasonably current tools. If I need bleeding edge on Pop!_OS I’m more than capable building and installing them if needed. Pop!_OS might not be perfect in your eyes, but for me it’s more than good enough and it’s not an constant annoyance like Windows 10 evolved into. It will more than do for me.

silly coding

Normally I stay away from most sites devoted to technology and discussions of it. But the other day I stumbled upon a story with the common lament that crops up periodically on such sites about how stupid other coders are. No real examples, just hearsay. In this story the examples led off with supposedly bad web sites that presented horrible (to them) entry fields. The story contained other examples of bad coding and the eventual eternal question: why can’t today’s coders write “good code,” good code being defined by the commenters in the story.

The same story linked to this old blog post from 2007 titled “Why Can’t Programmers.. Program?” (link: ). This post is a good fifteen years old. A tremendous amount has changed since it was published. Existing programming languages have undergone fundamental evolution, new languages have come into existence, and programming fads have come and gone. To agree or disagree with this post at this point in history is a bit pointless. But it did provide something amusing for me to do; writing a FizzBuzz program in Python.

The rules for FizzBuzz according to the post are simple enough:

Write a program that prints the numbers from 1 to 100. But for multiples of three print “Fizz” instead of the number and for the multiples of five print “Buzz”. For numbers which are multiples of both three and five print “FizzBuzz”.

I made one important change such that I always print the number so I can check manually if the output is correct or not. Here’s the Python code. Yes, it’s absolutely without “elegance.” I have no use for elegant code, because that’s the code with the most bugs and the most difficult to maintain.

#!/usr/bin/env python3

for i in range(1,101):
    if (i % 3 == 0) and (i % 5 == 0):
        print("FIZZBUZZ {}".format(i))
    elif (i % 3 == 0):
        print("FIZZ     {}".format(i))
    elif (i % 5 == 0):
        print("    BUZZ {}".format(i))
        print("         {}".format(i))

And here’s the last 11 lines of the output.

FIZZ     93
    BUZZ 95
FIZZ     96
FIZZ     99
    BUZZ 100

You’ll note in my implementation I print it all, the indicators along with each number. As I wrote earlier that’s so I can trace and check manually if the output is correct. There’s also another reason to do it this way.

In my deep past I’ve needed to hire folks to fill open admin spots. A test I’ve used in the past goes something like this:

  1. Write a simple program to out text, based on whatever criteria I use at the time.
  2. Pipe that text output to a file.
  3. Use Unix command line tools to search for certain patterns in the text from the file.
  4. Pipe the output generated in (1) into the same command line tools to search for the same patterns in (3).

I didn’t care what language they used as long as it produced the needed output. If I were to do this again, I’d adjust the test thus:

  1. Write a FizzBuzz program in Python and produce the output based on my given criteria.
  2. Pipe the output into a file.
  3. Use Unix command line tools to read the file and search for every instance of “FIZZ”, “BUZZ”, “FIZZBUZZ” and lines that don’t have either, and count the number of lines.
  4. Pipe the output generated by your FizzBuzz program into Unix command line tools to perform the same searches and counts in (3).

The purpose of all of this is to plumb their programming abilities a bit, as well as their abilities to problem solve on the command line. One solution to count the number of instances of FIZZ would be ./ | grep -w "FIZZ" | wc -l. This yields a count of 27 lines. If you want to see exactly what the grep is producing then pipe grep’s output into wc -l. The key for grepping the whole word is grep’s ‘-w’ command line switch. That works for the first three word searches. Searching just for blank lines (no words) is a bit more complex, with at least two general solutions. For extra credit, the candidate is required to save the grep output before counting the number of lines, which means they need to know how to use tee.

I’d give a candidate no more than 30 minutes to do all of this. If they’re any good at all they’ll have it all done in far less time.

While I did say it was pointless to argue with a 2007 blog post, I will take a single exception. The was a comment in the 2007 blog post concerning recursion. A quote within that post called recursion as a way to solve a real problem. I do beg to differ. I come from a background in which recursion was to be avoided at all costs. Part of that comes from my initial background straight out of college (we’re talking mid-1970s here) where I was an embedded programmer. Iteration should be your first choice to solve any problem that supposedly calls for recursion.

I provide for your entertainment two implementations of everybody’s favorite recursion excuse, factorial, written using iteration, not recursion. First, a hoary old piece of Python I wrote about in a post on this blog back in 2014:

#!/usr/bin/env python3

import sys

def fact(n):
    a = 1
    print( n, end="! = ")

    while n > 0:
        a, n = a * n, n - 1


if __name__ == '__main__':
    if len(sys.argv) <= 1:
        print("Factorial calculator. Must call with at least one number as an argument.")
        print("Multiple numbers can be entered on the same line, as in '1 2 3'.")

    for i in range(1, len(sys.argv)):

And this is the same code re-written if you will for Julia:

#!/usr/bin/env julia

function Factorial(n)
	a = BigInt(1)
	print(n, "! = ")

	while n > 0
		a, n = a * n, n - 1


if (length(ARGS) > 0)
	for x in ARGS
	print("Factorial calculator. Must call with at least one number as an argument.")
    print("Multiple numbers can be entered on the same line, as in '1 2 3'.")

They both produce the same output (although I leave it as an exercise to the reader to determine if it’s correct):

What I find interesting are both the strong similarities between Python and Julia, as well as their interesting differences. For example Python can handle big numbers transparently. For Julia, you have to declare a variable as a big number by initializing it with a BigInt (see  line four in the second listing). Command line arguments are accessible directly in Julia, while Python requires you to import sys, and then work with those classes. I deal with both languages through Jupyter, but that’s a post for another time.

Neither one of these examples will win any awards. They’re both blindingly boring, and frankly, I strongly believe code should be written that’s boring. I hate “elegant” code. Boring is one trait of good code that allows it to be fixed if bugs occur or to allow extensions for new functionality.

Generally I’m old and retired and way past caring about the majority of this. But on this point I do care about the negative effect of the trolling critics who make those who are trying to produce better code and trying to improve their coding skills, nigh impossible to succeed. It’s the trolling critics that make it nigh impossible for all of us to have nice things, and to have good people produce those nice things.