Now here is something new and different.
A new instrument. I have yet to buy an instrument for myself. Mostly on the account of being “kicked out” of music school for not having enough talent in primary school. Well, the desire to push keys transferred to a different kind of keyboard, which instead of noises produced system calls.
Now this is a direct result of visiting the Guitar Museum in Umeå, Sweden. Catching the guided tour by the owner, who went above and beyond to explain and show off the collection (specially since there were only two visitors there and some knowledge of rock and roll history was shown), kick-started this whole “something different” thing. If you have a chance, I cannot recommend it enough.
As you do, after such an experience, you find a music shop for a souvenir or two (beside the t-shirts from the museum itself). Long story short, there was this micro bass, on sale, which being cheaper than some lunches I had in Scandinavia, fall under the category “why not”.
Well, this opened up a convoluted rabbit hole of diving in to bass related music research.
What I got was a lovely Ibanez mikro bass model GSRM20B.
Flailing with the new toy, one potential improvement became obvious. The thing has a bit of a “neck dive”.
If nothing else, I am an engineer, so off to do some calculations.
The math comes to the torque, because of the position of the center of gravity, being about 2.3 times grater towards the front of the bass.
This can be improved.
This is not the first time trying to get into plan9. There were, in fact, several attempts while playing an OS tourist to try it out. It did not last past running a ls command or two.
It felt like trying to run before you could walk. While researching it more now, there is a method to the madness, and some valid points to be made. A design not slowed down with the past, an interface with graphical capabilities included from the get go. Everything is a text in a file rendered on a frame buffer, resulting in an endless history. Great! Ability to edit an already executed command in place anywhere in history and “plumb” it back to being executed. Fantastic! Forcing you to switch input devices to repeat a previous command. Not that great!
Looking in to it, the sentiment is mostly “this way or the highway, get used to it, it’s way more efficient”. Now, having some “mileage” after me, I can partly confirm. Some things are faster, the plan9 + rio way. I have timed myself. Editing a long command or a complex awk or sed command with regex, it is truly faster and more efficient to scroll up, click where in the line you want to make a change, make a change, select the line and middle click to plumb it to be executed again. It is not faster to execute the same command again that has a lot of output, driving the history up (I like sensors, and development of that brings many executions of the same command and reading output). It is not faster if the command has been run in another window. It is impossible to get to a command that has been executed in a previous session unless you saved your window history. Which is easy to do (cat /dev/text >$home/some_name_for_history.txt) and then grep through it. Well, now you’re doing shell history by hand.
But more importantly than any of that, for me, it breaks the flow in my mind. I used the keyboard input device to execute a command. I would like to execute it again. Or if I made a mistake, I would like to correct it. Or, most importantly, since this was the blocker for so long, I am learning and would like to try out some variations. To do any of that, I either have to retype the whole command, which can get tedious or troublesome if I don’t remember the command from a previous session, forcing me to slow down, stop or entirely change what I’m doing. Or change input devices, click somewhere, scroll, click, select and click again to rerun a text command, typed in through the keyboard.
All of this made it feel that I’m not actually learning to use the system, but rather starting a context switch away, fighting to learn how to learn the system. And yes, trauma builds character and all that. It doesn’t have some truth in it (we’ll get to that). But putting unnecessary blockers helps no one.
Story time explaining the writing so far. For a time, I worked as a TA, an assistant to a professor at a Computer Science faculty at a university. I inherited the workshop part of the course “Signal Processing”. Basically, explain and show the students how to implement and use math to do signal processing. The workshop, I inherited, was such that each student could use whatever programming language / framework / libraries they wanted as long as they produce the required result. Sounds great on paper, let everyone use what they are comfortable with, it will be more efficient that way, what could go wrong. It was catastrophic! In reality, instead of working on concepts, math and algorithms, most of the time was spent figuring out what version of which library from the internet will compile with what version of what language or framework so that it can be run on what version of operating system (we were a CS faculty; so Linux, Windows, MacOS, BSD, DOS, we don’t care, your computer is your tool, you should know how to use it, and the science should be the same for all). The workshop alone had about 15% percent drop out / repeat rate, where the students had to retake it. This didn’t help anyone, and it was a huge waste of time for everyone involved. So, after some research, I realized that the way to improve the situation, is to remove the blockers and bring the learning “one context switch closer” to the subject. I completely reworked the workshop. From “you decide what you want, so you get the results” I went to “we’re using Python, this version, plotting with this library, this version, and handling IO with this library, this version”. Basically, use this set of tools to get the required result. Yes, this did decrease the freedom, and I got a lot of flack from the students because of it. But the result was, that instead of dealing with the system to learn about signal processing, we now spent the majority of the time learning about the math and algorithms and actually working with signals. Instead of figuring out why this version of NAudio library for C# works under Windows Vista but not Windows 7, or which version of some other IO library can be compiled with which version of C#, there was actually time to figure out why this implementation of Fourier Transform is wrong or how do we get from a set of differential equations for a 1st order low pass filter to an implementation of a running average in C on a microcontroller. Using the system or the tools, was a solved problem (I could have better examples, tested the required software, students had a common base and could help each other and no time was spent trying and deciding what/how to use the tool to get the job done). This decreased the drop out / repeat rate to about 1%-2% and (however horrible it sounds) those 1%-2% actually never made it to the end of the study. All this, learning the actual subject not the system to work on the subject increased the student’s knowledge (to the point it went from one of the most feared/hated courses to “nothing special”) AND saved everybody a lot of time and effort.
What does everything written so fat have to do with anything? Ironically, the tile is “The case for doing it your way”, yet all so far has been written is an example where the freedoms have been reduced. Well, that’s not the only thing that was written. Let me reiterate the point. Remove the blockers or unnecessary layers to knowledge. Solve the problem! You are however allowed to bitch and moan about it along the way (I have/am/will).
The problem about learning plan9, for me, was the context switches between input devices in my head. What I expected/needed/wanted was a command history.
Something to let me try out a different flag in a long command without retyping everything or fussing around with a mouse pointer (I will spare the rant about one pixel borders in rio, which probably worked great on a 480x320 resolution, but now the mere act of letting the mouse go will move the pointer and make you type somewhere completely unintended), something to let me fix my typing mistake and run it again without the need to retype or switch to a mouse, something to let me find a previous command and flags I have not yet memorized, but I know I ran it three commands ago without scrolling through a wall of text, something to let me use a command from the previous window or session or boot because I don’t know them yet and for a system designed to be a successor for Unix it certainly pressures me to open my analogue paper notebook a lot.
So, I set out to build a command history for rc shell. I managed to pull together something. It’s probably not perfect. And reading about the way people use plan9 will probably be scoffed at as unnecessary. But it gave me a chance to get used to the system and not fight it (it was coded in acme). And I think it follows the spirit of plan9; separate utility, that you can configure the way you want it (from just saving your command history to in command line browsing through your command history, either just for this window or globally through all windows and sessions). I solved the problem my way, by building a tool which you can use any way you fit your way.
And a note on development for the end. Honestly, working on this, felt like a huge hack (abusing kbdin buffer to implement browsing trough command history in place), but then you ran across the issue of hstr for bash of your system stops working because with the newer kernels the “fake input” for serial and terminals have been disabled. And you yet again come to the realization that it truly is the same sheeet everywhere.
Different how?
As in how is this different and how to make it different.
One thing I wanted to try and learn is plan9. Not just for the academic reasons for being a test bed for modern concepts like containers, network first design and simple enough base to develop other technologies on (UTF, GO, /proc file system, …). More simple than that, it was different. Too different. If felt like learning to run before walking. Combining that with the lack of time and only starting in the studies of computer science, the interest didn’t stick. But it also was not forgotten.
So now there is some time again, and this time a sizable amount of experience. Let’s try again.
Just one thing first, a piece of advice from being a student to working in the academia. I have yet to see a successful knowledge acquisition without a reason. In other words, there needs to be a goal.
A goal for this: have a system to publish thoughts, notes and bits.
And with the magic of technology, events in the past can be published on the results from the future.
Now let the adventures begin.
It’s time for something new, something different.
It might be time in someone’s life, accumulation of experiences looking for structure, a need for a shift in perspective or just an awakened drive to learn something new.
As with any burn out, heartache, creative block, … The best remedy: try something different! Let the proverbial weight of new experiences push you again on the right path.
With that said, a journey of discovery awaits as always. But this time around, having the opportunity to do so, document it here in this form.
