Finally I am able to work under windows – with wsl 2

I have to admit that I was not able to work on windows ever.


I mean I tried, but my workflow was not fit windows. I use the terminal and gnu stuff mostly, I do not use an IDE, I use vim and shell, and that is good for me.


That means I could work with Linux… mostly. But all the time I tried, I hit walls as there were a VPN software I had problems to work with, or some video chat app, or an admin tool for eg. Netware, or simply the computer my employer-provided was not working with Linux, it’s battery drained super fast, or the touchpad did not work well, you name it. And I know that there are machines which has excellent Linux support, like the Dell’s XPS developer edition or some Lenovo machines, but I never had those. – I even had a year back in the early 2000s when I used FreeBSD as my main OS because the PCI modem I had money for wasn’t working good with Linux. (It wasn’t worked well under Windows tbh.)


Back in 2009 I bought my first iMac, and working on that machine was awesome! Everything worked out of the box, there was no hardware which would cause any problem, and when I had to code something, I just opened my terminal and started work in an environment, which was pretty close to a Linux experience. I needed to change a few utils for their GNU replacement, but that’s all. I was able to work on my Mac as I was able to work on my Linux box – but it was way better. Hooray.


Years passed, and my main work environment became OSX, I loved it, I had a fine Macbook Air, and everything worked as it was planned for.


One day I bought a PC for home because I wanted to play video games, and sometimes I tried to work with that, but I was not able to, as my work environment were just not fit there. I tried everything. I tried to run Virtualbox and ssh-d into that, but I hated all the terminal emulators I’ve found. It was simply inconvenient every possible way.


In the meantime, my love with the Mac ended – the ‘new’ series for MacBook pros with touch bar and crappy keyboards just killed the experience for me. I am still working on a Mac because that is still the best option, but the love is gone.


When WSL was released, I tried to use it, but it wasn’t good either. I missed locally starting my daemons such as MySQL or Docker, and it was not fit to my workflow. Of course, I was able to run my services under windows, and access them from my WSL installation, but it wasn’t good. It was a bad experience. The best thing I was able to do to spin up a cloud instance and use my WSL installation to ssh into that.


When I first hear about WSL 2.0 it sounded great to me, so I decided to try it out as early as I can. I rolled into the insider program and I installed a version which had it included and started to work with.


So far it is good. It provides me the Linux experience from the moment I open my terminal. All my workflows and utilities behave the same was as I was used to, and it has a seamless integration to my windows desktop.
`

What to do with the one-shot scripts

I can’t really answer this question, but I am really curious.

During work, I often have small(ish) tasks to solve, and when it is possible I rather write small one-shot scripts instead of doing some manual labor.

These scripts are rough, they are not made perfect because they don’t have to, they have one purpose, and they have to do it right. Sometimes they have small mistakes in them, sometimes they just aren’t perfect, sometimes they are awful. There are always compromises when creating these like ‘does this task worth that plus hours to put them, or just aim for the solvable problem’.

Let me show this in an example. Today I am working on a script what copies big amounts of data between two servers, I want to do it multithreaded, but I also want to limit the number of threads.

My quick and dirty solution looks like this:
for row in cursor:
while len(threading.enumerate()) > MAXTHREADS + 1:
time.sleep(.1)
worker = Worker(row)

Yes, I know, civilized people don’t use ‘sleep’, because that is a waste of CPU, but hey, I will run this script on an ephemeral EC2 instance, so I really don’t care. This will do it, so deal with it.

But after the migration, I do want to keep this script somewhere because it is possible that I’ll need something like this in the future, and I don’t want to reinvent the wheel then.

My GitHub account would be a perfect place for them, but I am not sure if I can put them there. I mean GitHub account is like a business card (remember Patrick Bateman), I don’t want to put ugly code them – I mean if I want to find a new workplace, then it will be possible that they will check my GitHub stuff, and I don’t want them to think if I am a bad coder.

If I had a paid account (which I don’t have) then I’d put these into a private repo.

Nowadays I put these into gists, but gists are not easy to search, so that is not perfect as well.

I am not sure what would be the best.

 

Going back to my Macbook Air

I started to work at my current company at 2013. In that year I got a maxed-out MacBook Air, which I loved a lot, but it became a bit storm-beaten, I poured some coffee into it (two or three times) – the first one led to a mainboard replacement, but the others were forgotten, and once my son hammered it a bit – few damages on carousel, and a broken charge connector which was repaired.

Last year I got a new 15″ maxed-out Macbook pro, and I really didn’t like it, so I was procrastinating the switchover for a few months after the machine was on my desk – I got the machine around May, and I moved on that around October.

And I bought my old laptop from the company because I liked it.

I use the new machine for three months so I can articulate my opinion about the new MBP series: they’re a glorious piece of shit. The keyboard is awful – the worst one I had for years, my fingertips are hurt a lot – I have to type really strong to get the feedback, and that is painful. The machine is too big for me, it is not convenient to put it into my lap, I have to hold it there, not just put down. The touch bar is useless, but at least it is easy to accidentally touching it, which will lead to funny moments like reloading a webpage which I use, and the apps I am using not getting any advantage from it. For example, I can change my terminals color scheme, or I CAN OPEN A F*CKING MANUAL. That’s just wow. I really needed that, thanks, guys! And as a heavy vim user, I really don’t need a physical escape button for sure.  The force click touchpad is useless as well, but at least I had to learn a new way to interact finder, and I just don’t want to talk about USB-c.

So, I decided to move back on my old MacBook Air.

 

 

OSX and case-sensitive file system

I am really angry now.

A few weeks ago, when I was finished my MySQL backend checker I lost about two hours of work because I wasn’t commit anything to git, but I overwrote the working file with one of my doodle files – which file had the same name but with camel case. I had a default APFS filesystem (on High Sierra) – which is not case sensitive. This was a real amateur mistake I admit it, but the damage was done, I had to recreate everything (actually the second time I was way faster, it took around an hour.)

Continue reading “OSX and case-sensitive file system”

My MySQL command prompt

Earlier this week we had a discussion with fellow DBAs about our mysql prompts, and at the end of the day it showed up, that a lot of us hit the same problem.

The problem is, that when you set up your mysql prompt then ‘\h’ will be resolved to ‘localhost’ when you connect locally – instead the name of your host as you expect it. It always bugs me, and once I spent a good afternoon figuring out how to workaround this.

Well, the workaround is not a big deal, because you can insert any text into your mysql prompt, and after you realise that you can do it, then it is easy: just put the hostname into your prompt with your chosen provisioning tool and that will do.

Continue reading “My MySQL command prompt”

The way I like to compile my Go programs – Makefile

I was on the quest of searching the Holy Grail of Go programming, and I found something, which I doubt that it is, but close enough – for the first sight.

I have several problems with GO, first, that I write my code on an OSX box, and I’ll run the programs on Linux hosts, so I have to solve the cross compilation; my second problem with Go, that I don’t really like the “There is a GO project folder, and all the GO projects are relying on” approach. It makes using GitHub painful.

Continue reading “The way I like to compile my Go programs – Makefile”

My work environment

I was thinking if my work environment would be interesting or not, but I decided ‘yes’ – because I always like reading about others work env.

I am working with Linux/UNIX for more than 15 years now, and I have tried a lot of cool tools, but at the end, I always found myself using the same apps in the terminal.

I like the Unix philosophy about Do One Thing and Do It Well. I never really use big, bloated software, I like to use my editor for editing files, and my git client to use git. That’s simple.

Continue reading “My work environment”