Same ramblings and ruminations in the moment.

# Tinkering on Windows

Terminal access has become so integral to the way I interact with computer systems that when I finished building my gaming PC a few months back, I immediately began looking for ways to enable this on Windows.

I didn’t want to deal with dual booting since a lot of the time I work by interrupts. Having to restart my computer and select OS by the bootloader would require a mental context switch, which is not preferred. The last time I used Windows, I remember comparing the performance of Virtualbox VM with an early version of the Windows Subsystem for Linux (WSL). I started there to evaluate my options.

## Learning Powershell

Out of the question. While this might work for higher level work that to the dev is system-agnostic, I really didn’t want to learn powershell.

## WSL/WSL2

This was pretty promising at first, as it had been a while since I had first used WSL when it was in beta. Had some initial troubles getting it installed due to conflicting hypervisors, but I eventually got it working. I use this as my daily driver since it spins up so quickly. Of course, I can’t use this direcly like Linux, so for other projects I must use another solution. This was apparent when I first tried to install Jepsen, which requires access to cgroups. You also can’t use systemd, which while controversial, is necessary for installing certain projects.

WSL was good for various web projects, as it did not rely on features of the operating system by nature. Docker Desktop on Windows and WSL integration was also a pleasant surprise. All this seems tuned for web developers though, e.g. as long as Docker works, no need to dig deeper into system-level stuff.

## Virtualbox

It was a bit clunky to use, and involved a graphical component that I was unfamiliar with. I could run it in headless mode of course, but I ran into various issues in getting it installed. There was a weird Hash sum mismatch when using apt that I seemed to only get in Virtualbox. I tried for a few hours to get this debugged, but decided there was a better use of my time. Something had caught my eye when I went on the Ubuntu website to download the latest ISO that I hadn’t seen before – something called Multipass.

## Multipass

Multipass is a CLI tool to spin up and manage linux virtual machines. On windows, it uses Hyper-V, and its calling syntax is quite similar to Docker, which is a plus. I’ve since settled on using WSL2 + Multipass. WSL being my daily driver, and Multipass when I need to run certain projects in a Linux machine. For example, I have an Ethereum fullnode for development running in a single Multipass VM.

To avoid many layers of virtualization, I’ve installed Multipass directly on Windows, and am using the CLI tool passed into WSL, e.g. alias multipass='multipass.exe'. This presents some problems when mounting directories outside of the WSL filesystem. A workaround is to just launch multipass in Powershell, which has access to the classic Windows letter-name drives.

multipass.exe mount D:\data\ default:/data


It’s still a bit unfortunate that I have to use powershell for this, but once the VM is started with the right volumes mounted, I can use WSL to manage it. SSH also works nicely with multipass, so I’m able to connect it with remote editors like VScode.

## Next steps

I’m happy so far with this setup. Granted, I’m not doing too much work with this setup these days, as I use a Macbook for work, but I’ll see what I can do in my spare time tinkering with things. Next step is to get a cluster of VMs up and hook up the networking so it works with kubernetes. It would be fun to play with public blockchain fullnodes and do some tinkering there.

# Lofi

I grew up with a Yamaha P-80 keyboard being one of the centerpieces of the house. As a child, I was pretty set on the few interests I had, and music was not one of them. While I attended weekly piano private lessons, I never really found joy in playing unless I needed a quick break from whatever I was working on, or if I had nothing better to do. In high school, I was briefly involved in a small band a few friends and I had formed to perform at local fundraising events, so our keyboard got much love during those times, but after I had left for college, the keyboard once again gathered dust on its keys.

Recently, out of boredom and subsequent increasing openness to explore, I have discovered the art of music production. What started off as a way to bang together a few notes after work and have it easily recordable to share with others turned into one of my latest hobbies.

In the past, I considered anything non-technical or that provided no immediate value to be at most a fun non-productive waste of time. Especially now with the world seemingly slowing down, there’s less of a need to be hyper-productive and “hustle mindset”. Looking back, the reason I thought the way I did was to pursue the path of most immediate impact and gratification. Understanding the most recent blockchain whitepaper or hottest topic in tech was the fastest way to be impactful. Recently I’ve learned to place an increasing emphasis on being well-rounded all around – meaning more than just being a generalist tech person. This might be evident in the way my reading list has changed over time. Also check out my noobie Soundcloud.

# Personal Brand

I was recently invited to give a short presentation about my experience working in blockchain for the Blockchain for Developers DeCal. The staff have been hard at work revamping that course over the last few months, and it’s been great seeing their progress, especially when compared to the DeCal’s first iteration 3 years ago. One of my first experiences in “blockchain” actually, was to maintain the Blockchain for Developers DeCal website and also edit their videos, while auditing the class. Oh how times have changed.

Since I’m fresh out of college, I figured I would reframe the presentation as a personal narrative. Instead of it being about “my experience working in the blockchain industry”, it’s now about “my experience learning blockchain” – from when I was a student who just barely understood cryptographic hash functions, to now where I hopefully know at least a tad bit more. Especially in the blockchain industry, popular startups and their founders achieve demi-god-like status. This causes many to think that they too should rush to achieve such clout. This can be seen partly as entrepreneurship, but of course, everything must be in moderation.

To chase the high of having instact gratification and impact in the blockchain space, some students might neglect their studies. While they might learn a great deal about the newest stable coins or smart contract programming languages, they risk missing out on the big picture: something universities and large research institutions have experience teaching, especially if they have the nerve to teach the same curriculum for decades. Of course nothing’s inherently better or worse for all indivuals, as everyone has their own way of learning, but explicit action (note the word “action”) to seek fundamental truths and context should be more widely valued. Otherwise, the next hot startup might realize too late in production that (1) blockchain is actually not required, and (2) they ended up reinventing the wheel in some areas. Members of the Education team at B@B have always understood this: that blockchain is a very specialized solution to a specific problem, and aspects of which have been applied to solve other problems. This is inherent in the name of our primary curriculum: Blockchain Fundamentals.

Part of my presentation argues to take it slow and learn the fundamentals, and to not conflate motion for progress. The rest consists of my experiences learning blockchain, and the various life lessons I have accidentally learned along the way:

• “Extract simplicity instead of mastering complexity” - Scott Shenker and various networking gurus
• Focus on breadth, but understand that breadth can only take you so far
• Track your progress, and reflect to bring it back to simplicity
• Have fun, and learn by accident

Normally, when giving presentations, I would just use the B@B slide deck template, as I’ve been using that for years now. However, it dawned upon me that I’m no longer a student in that org anymore, and that this was the first presentation I’m giving after graduation. (Diploma actually came in the mail yesterday!) Guess I’m in the next stage of my life – time to revamp everything! Hence forth, everything shall be various shades of gray, blue, and purple, and consist of the fonts Oswald and Roboto Light :)

# edX Open Remote Access Program

I handed off our two edX courses to the university and a few student administrators from Blockchain at Berkeley in 2019. After a long year of hard work and dedication, and some time after that administering the course and connecting with students, I was ready to finally take a step back. By then, we had already completed four course runs - first an instructor-paced run, followed by a self-paced run, for both courses - and were scheduled to launch once again. Looking back, it was a wild ride, and thinking about it now got me feeling quite nostalgic.

A message appeared in my inbox the other day from our faculty advisors, announcing the university’s participation in edX’s new Open Remote Access Program in repsonse to the world’s troubles migrating education systems to remote during COVID-19 crisis. In particular, they wanted to make our courses completely for students, including all graded coursework. It’s great that in these crazy times open education is ramping up more than ever. Teachers everywhere are making their materials open, and especially in universities, lectures are being recorded when they weren’t before.

# Dotfiles & Managing Complexity

Dotfiles summarize a lot of what I’ve learned recently about managing complexity and seeking reasonable fundamental understanding above all else. I’ve always known to attempt to understand things at a high level and view learning as a process that generally starts from the top down. However, what that meant in real life as an actionable algorithm for the daily, I was a bit more unsure. Like many things I find myself involved in, without careful attention, it converges into a situation of all theory and no implementation. Without a proper understanding of the fundamentals and the high level overview of what you’re building, its easy to to know what you want to do but not know how to make actual meaningful progress. You need to strike the right balance.

I’ve always thought that it would be pretty cool to have a completely decked out terminal setup, with all the fancy shell bells and whistles, text completion and project file indexing in vim, and having memorized all the keybindings – flying through the terminal with hyper-efficiency. However, I never really found the time or need to do something like that. I edited my bashrc every now and then to add a convenient alias to the directories I used to store code for classwork or the like, or to add some new tools to the path, but that was the extent of my terminal tinkering. I still spent a lot of time in the terminal, but preferred to use some other graphical tools to do development instead (e.g. VS Code). There recently came a need at work to spend more time the terminal on a remote machine, so I was unable to use my existing tools. And given the shelter-at-home restrictions, I figured it would be a good time to finally sit down and make my computer my own.

I was quick to jump on GitHub and copy the first and highest rated vimrc’s, but found that I could never tell what was really run in the background, what keybindings were enabled, etc. – thus, it felt more like a hinderance that happened to look nice than anything actually useful. I was looking for a shortcut. In these situations, spending time looking for shortcuts ends up taking longer than actually doing it the right way. Also, as I later came to realize, dotfiles are pretty private to each person. You can’t just use someone elses’s configuration and expect it to work 100% with how you work. You need to make it your own.

So, I took a step back and reverted all my configs to their base form. I used naked vim, tmux, etc. for a while, and configured as I saw fit when the time came for me to do so – often when I found things to be clunky. Of course I still borrowed snippets of some people’s dotfiles, but knowing exactly what I was putting in where, and for what reason, really made things more managable. Tying this back briefly: I always knew what I wanted in theory, and knew what tools to use: a text editor, terminal multiplexer, etc. but in attempts of doing everything at once, I made little progress. Only by explicitly seeking to understand things firstly at a high level but then easing gradually into lower level understanding does it make things more manageable. So I’ve found that a necessary prerequisite to really mastering complexity is to extract simplicity. Walk yourself down to lower and lower levels of understanding gradually, and you’ll get there in no time. It sounds simple, but to put it to practice takes some real discipline, it turns out. And when it comes to dotfiles, you gotta be your own person!