everything wrong with free software
"free as in speech"
*originally posted:* sep 2022
ask people to explain computing in as few words as possible, and many will start telling you about 1s and 0s. theyre not wrong, binary computing is very useful and quite relevant in our modern world of tiny silicon-based switches.
but if you want to understand the fundamentals of computing, 1 and 0 doesnt tell you very much. a few computers, like the harwell-dekatron witch, even processed or stored numbers in base 10 like we normally do on paper. but what are these numbers doing?
as mentioned in the first chapter, modern computers evolved from automatic calculators. creating a program is really telling the machine to move numeric values into certain places.
at the most fundamental level-- where i never do much of anything and a "low-level" coder could tell you far more, you are working exclusively with numeric codes for everything.
if that sounds incredibly tedious, it is. the main thing that people do on this level (called "machine code") is find ways to make coding easier.
in the very early days (the 1960s were futuristic by comparison) when someone wanted to use a computer, they would do all of it in numeric machine code, or they would punch data into cards that helped correspond single-character codes with numeric (consecutive) physical positions that the computer could read with a card reader.
these numeric codes went into "dictionaries" or paper code books. after some months or so, you might find that you had a dictionary with several useful computer "routines" in it.
the goal of making these hand-coded dictionaries into automatic programs became the basis for the first compiler. like the basic interpreter mentioned in chapter 2, the job of a compiler is to translate codes that are friendlier to a human into numeric codes the computer understands.
this was a revolution for most of us, and while it started in the 1950s, by 1964 this revolution was exactly what made a beginner friendly computer language like basic possible.
now instead of coding the letters h-e-l-l-o (space) w-o-r-l-d into numeric ascii codes (or baudot teletype code, since ascii didnt exist until around the same time basic did) and then entering the code to move the numeric data somewhere that it can be output to the screen, you just say:
10 PRINT "HELLO WORLD"
and run the program. seems like a lot of trouble just to say two words, but before that it was a lot worse!
if you have followed along and actually installed openbsd on your "thought experiment" pc, you can run a single line of code very similar to the above line. just type:
echo Hello World
it will do exactly the same thing, only this command is for a 1970s-unix-style "shell" interpreter, rather than 1964 basic.
the difference between an interpreter and a compiler is a like the difference between hiring a personal translator and commissioning a translated work.
if you are talking to other people, and have a translator with you, the translator will do the "interpreting" for you as other people talk. every time you run an interpreted program, you need to run the translation program.
while this has certain costs in terms of efficiency, it means that when you want to change something, you dont have to wait for it to translate the entire program again-- you can just start running the new version of the code immediately.
a compiler on the other hand, translates the entire program into computer-ready instructions. whenever you run the compiled program, it will run without being compiled again-- but every time you change something you have to wait for the entire thing to compile.
the general rule is that compiled programs are better for tasks where speed is very important, but interpreted tasks are better for code that is going to be constantly tweaked.
many, though not all of the friendlier languages are interpreted, because it is easier to find and fix problems with shorter waits (or more complicated processes) between edits.
when you first run bsd from the command line, its not obvious whether the thing youre using is more sophisticated than the chip from the early 80s running basic on the c64. thats because all it gives you for an interface is text on a screen.
if youre used to fancy rectangles with animation and even video, you might look at a simple command prompt and wonder if this is just a throwback to the 70s. but this is an old cover on a much newer book.
someone who has only used dos or a c64 can marvel at everything openbsd has behind the prompt. with a single command you can download a file or a webpage from the internet. (at least, if you have wget installed). you can play your mp3 files from the command line. and you can run python, which is more advanced than pretty much any basic interpreter or basic compiler, ever.
whats more, you can make it do these things automatically, in response to certain events or specific times-- you can even make it do these things in the "background", so that you can keep working or have it do more than one task at the same time.
sure, you can do all of those things with a graphical system as well. and you need a lot more code to make that happen-- and lots more code means lots more opportunities for large projects to go wrong.
apart from being a geeks canvas, the command line is also where you go if some parts of the system (like all that graphical stuff people run on top of the os) arent working properly. you can fix a number of things from the command line; its a bit like opening the bonnet of your car.
but the best part about the command line is that its faster and easier to write code for. nearly all frameworks for graphical tools add considerable overhead in terms of resources and code you must tend to.
when you talk to a voice assistant, youre doing something very similar to using the command line.
selecting things from a series of menus can get tedious when you know the things you want. imagine if instead of telling someone "id like the chef salad" your only choice was to open the menu, find the salad you wanted, and point to it-- and you had to order everything else that way too. when people order fast food, having a menu in front of them often slows them down.
if you had to order that way every day, or for 20 people, you would really start to hate flipping past page after page after page after page, poking at every item with your finger. sometimes menus help with unfamiliar tasks. then again, dos had menus for the command line as well:
1. run tetris
2. run word processor
it isnt the point of this chapter, but you could, with only things available to you from the openbsd base installation-- code a little menu that displayed a list like the one here-- using numbers to run each relevant command, with a number (or letter) that could tell the menu to quit.
sometimes, instead of creating a menu, the easier thing to do is just take a command that already exists and give it a name you prefer.
if you like the editor called "vi" but prefer to say "edit" or even “e” (why not both? you can do both if you want) you can create a second command so that whenever you hit the letter “e” and then hit enter, it will run vi. thats even less work than hunting through icons on the desktop. setting this up is also less work than creating a menu.
you can do far more than that, but menus are nice and easy. shortcuts are nice and easy. graphical environments can hide a lot of complexity, but they introduce even more of it in the process.
im using a graphical environment to type this (including the new version of the chapter)-- in a window next to other windows, in a text editor i helped create-- but did little of the original coding for.
and im running it in openbsd. so dont think im "fundamentally" against graphical environments or anything. a graphical interface is better, for some things-- sometimes. but it will also put a lot more on our plates.
license: 0-clause bsd
# 2018, 2019, 2020, 2021, 2022
# Permission to use, copy, modify, and/or distribute this software for any
# purpose with or without fee is hereby granted.
# THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
# WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
# MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
# ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
# WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
# ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
# OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.