publish (#1)

Reviewed-on: https://git.tomkarho.com/tomkarho/blog/pulls/1

misc/refjecting-on-10-years/meta.yml

@@ -0,0 +1,5 @@
+Created: 2024-05-01 10:20:00
+Updated: 2024-05-01 10:20:00
+Title: Reflecting On 10 Years As a Developer
+Slug: reflecting-on-10-years-as-a-developer
+Description: Some thoughts and musings about my journey for the past 10 years as a developer

misc/refjecting-on-10-years/post.md

@@ -0,0 +1,57 @@
+## Intro
+It has been roughly ten years since some poor soul decided it was a good idea to pay me to do this thing called software. Since this industry follows the Jem'Hadar rules or aging, this little milestone supposedly makes me an elder. So as a senior citizen of the IT world, why not dole out some thoughts for everyone to ignore at their leisure? Let's yell at some clouds, share some wisdom and put some pen to the paper.
+
+So here's my five "lessons for life in software".
+
+## 1. There is no work-life balance
+If you feel like you need to balance how much you work and how much you live, I fear you have already lost. To your work. So *waves a hand all jedi like* put aside that death stick, go home and rethink your life. Work is there to facilitate your life. Not the other way around.
+
+Work is there so you can live. You don't live so you can work.
+
+One more time.
+
+Work is not life. Life is not about working.
+
+Work to live. Don't live to work.
+
+## 2. Best practices are like opinions
+And like opinions, they are like assholes: everyone's got one and sooner or later it gets smelly.
+
+The best way to treat any blog post, book or declaration of best practices is to view them as a trend. Trends come and go. Treat best practices not as scripture but a nice offer of principles that might, **might**, work for you and your team. If it does, good for you. If it doesn't, well you'll form your own eventually and they are as valid as the guru you just read from.
+
+Let me put it this way: You read a blog post about best practices (as one does). Then a year later you read another that says absolutely opposite of what you read a year previous. It might be even from the same author! Are you going to refactor your entire code base to follow this new paradigm because your favorite guru told you so? Hell no (I hope that's your answer).
+ But they are all united in the desire to make work and life easier.
+So what's a code monkey to do? One word: consistency. That's really what best practices in the end are. Consistent way of doing things. Whatever rules you've got set up, stick to them.
+
+## 3. Fancy titles look like imposter syndrome
+I am a software developer. I am not a "software artisan", "code ninja", "devops master super engineering supreme commander" or my personal pet peeve, a "software engineer".
+
+Maybe I'm in the minority but I am predisposed to be suspicious of all things hype because usually if it sounds too good to be true, it is. The fancier and more pretentious your title sounds, more eagerly I start looking around for the curtain to see what's really going on and on whose face do I have to throw some water.
+
+Call me humble and maybe I am in the minority but it feels arrogant and presumptuous to invent some fancy name to describe what I do when what I do is not really that different or special than what others do. If you feel like you need to invent a new word to describe how awesome you are, odds are you really are not, but are trying to pretend you are. That's called lying by the way.
+
+Now, titles that describe a **function** of your work like a tester, devops, database admin and so forth are fair game because they serve to inform rather than impress.
+
+As the Bard put it: "This above all: to thine own self be true."
+
+## 4. And I too feel like one on occasion
+The imposter syndrome. Simply put, an idea that you are really not that good at your job and somehow against all odds you have been faking it this entire time. Your boss, your coworkers, your clients. Everyone somehow bought into the hype that is **you** and chose to give you money for absolutely nothing. Your entire career is a con artists wettest dream come true.
+
+Sound pretentious? Welcome to the paradox friend.
+
+It has been my observation that the panacea for this particular illness is not a pill but two things: time and experience. The more you do, the more you learn and what skills you have get honed further. That doesn't mean you don't get that feeling still on occasion. But you are better equipped at managing it and putting it aside. Because turns out, you are qualified.
+
+
+## 5. Curiosity killed the cat. Good thing you are not a cat.
+Software is an industry that moves at lightning speed. Almost every branch of this industry constantly changes and evolves. Tools change, new ways are invented to solve problems, abstractions are abound. Sometimes they are better, sometimes they are not.
+
+Imagine if you drove a taxi for a living and every few months you get a new car but the pedals are all different, the shift gear has switched position to the roof and instead of sitting down you are standing up. Or next time you are sitting down but the shift gear is automated. Or let's say you are a plumber and every few months you need to be certified for a new kind of a wrench that  But they are all united in the desire to make work and life easier.promises to double your torque.
+
+This is the reality IT and software as an industry is living in. Of course other industries change and evolve as well but in the software world that evolution cycle is much much faster and if you don't watch it, you might get left behind. So if one is to survive, the most important trait in any developer's toolkit is curiosity. The desire to learn new things and at least keep track of industry happenings. Yes that might mean spending a day or two to learn another JavaScript framework (sigh), database or a new fancy code offering but that's the nature of the beast today.
+
+That is unless you are a Cobol developer working for banks. Those skills live forever and you are set for life. Unless a Rust developer comes along...
+
+Anyway, dare to be curious. It will be rewarded.
+
+## Outro
+So there's some "rules" that I try my best to apply to myself. You might even call them my "best practices" for living and working. Some of them are just observations of phenomenon and how to overcome them. Other's at times even harsh lines that I try not to cross. I hope you find this little post informative, though provoking, and perhaps even entertaining.

tutorials/dual-booting-bose-quietcomfort-ultra/meta.yml

@@ -0,0 +1,5 @@
+Created: 2024-04-29 17:00:00
+Updated: 2024-04-29 17:00:00
+Title: Bluetooth 5.1 Headset In Dual Boot Environment
+Slug: bluetooth-5-1-headset-in-dual-boot-environment
+Description: A step by step tutorial on how to connect a bluetooth 5.1 headset to both Windows and Linux environment using Bose Quietcomfort Ultra a a case study,

tutorials/dual-booting-bose-quietcomfort-ultra/post.md

@@ -0,0 +1,228 @@
+Bluetooth 5.1 Headset In Dual Boot Environment
+===============================================
+
+## Intro
+In this tutorial we will attempt to allow the same bluetooth device (a Bose Quietcomfort Ultra headset to be precise) to be paired and connected to a dual-booted Windows/Linux system without needing to re-pair the headset every time you switch between operating systems. The process is cumbersome and requires many steps but it is not impossible.
+
+## The Problem
+When pairing bluetooth devices to each other, those devices keep track of each other via a mac address: an unique number-character combination that identifier a particular device. Pretty much every device that is used to connect to something whether it's a set of headphones, network adapter, an usb stick or a game controller, has an unique mac address attached to it.
+
+Imagine then that you pair a set of headphones to your computer. The computer now has a record of your headphones mac address and the headphones has a record of your computer's bluetooth adapter's mac address.
+
+Mac addresses however, are only half the equation. The other half is how these devices authenticate with each other so your headphones know which computer is allowed to send it sound and which is not. This is done via keys that computer keeps in it's record and these keys are generated every time a pairing occurs.
+
+So let's say that you pair your headphones to a Linux computer and then boot into a Windows operating system on the same computer and attempt the pairing again. It will work, but now
+the only operating system that has the correct key, provided by the headphones, is on Windows. Reboot to Linux and attempt to connect and you are met with an error since your Linux machine,
+despite having a record of the headphone mac address, now has the wrong key to authenticate and the headset has already cleared it's internal records for any authentication keys belonging to Linux. The simple rule of thumb is: one mac address, one set of keys.
+
+## The solution briefly
+The solution to this conundrum is simple (how to make that solution happen, not so much): copy the keys from Windows into Linux. Now there are multiple projects out there that have attempted to fix this problem but they seem to work only for older devices. More specifically devices that operate with bluetooth 4 and and maybe 5. So we'll do this by hand for now.
+
+## About Bluetooth 5.1
+Bluetooth had some changes to it as far as key management after version 5 or 5.1 (don't remember which). What happened was that things got more complicated (shocker that). In earlier versions of bluetooth, there was just one key to be concerned about. Now there are several. So if you do not find in your .reg file the necessary keys, there is a change that your device is of the older version. That means, you actually might get off this exercise slightly easier than I did. I suggest looking to [Arch Wiki](https://wiki.archlinux.org/title/bluetooth#Dual_boot_pairing) or search for dual boot bluetooth device and you'll come across several tutorials that will go through it. The process is virtually the same, just much simpler.
+
+I'll still suggest reading through the relevant wiki section for reference and potential extra help if these instructions prove insufficient.
+
+## How to make it happen
+
+Let's break this down into steps. We need to...
+
+1. Pair and connect our device in Linux
+2. Pair and connect our device in Windows
+3. Extract the necessary registry keys from Windows
+4. Transfer (and transform) the keys to Linux
+5. Update Linux configuration so headset will accept new keys
+
+Easy right? Weelll... the first couple of steps are.
+
+### Phase 1: Pairing On Linux
+The first step is rather simple. We pair and connect our bluetooth headset with Linux.
+
+### Phase 2: Bootin Into Windows And Pairing Again
+Step 2, not so difficult either. Just make sure the headphones are in pairing mode and once Windows pairs and connects, we are in business.
+
+### Phase 3: Extracting Keys
+Here's where things get a little trickier. We need access to windows registry to extract our keys and we can't just launch regedit. This is due to the fact that we need extraelevated privileges, aka SYSTEM account, to view all the information we need. To do that, we use [pstools](https://learn.microsoft.com/en-us/sysinternals/downloads/pstools). What you do is this:
+
+1. download pstools and extract to a folder (I use *C:\Programs\pstools*)
+2. open command prompt, powershell or windows terminal **as** administrator
+3. navigate to folder pstools
+4. run `.\PsExec.exe -i -s regedit`
+
+We should see now windows registry editor open.
+
+^^^
+![Windows registry when opened with PsExec](assets/windows-registry.png)
+^^^ Windows registry when opened with PsExec
+
+Navigate down the registry heys
+- HKEY_LOCAL_MACHINE
+-> SYSTEM
+-> CurrentControlSet
+-> Services
+-> BTHPORT
+-> Parameters
+-> Keys
+-> [BLUETOOTH ADAPTER MAC ADDRESS]
+
+Beneath [BLUETOOTH ADAPTER MAC ADDRESS] there is mac addresses for each bluetooth device paired. Other guides as I recall will ask to export a specific device registry keys but what we will do is export the the entire [BLUETOOTH ADAPTER MAC ADDRESS] device. That should give us a *.reg* file that looks something like this:
+
+```
+Windows Registry Editor Version 5.00
+
+[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTHPORT\Parameters\Keys\1cc10c325f27]
+"CentralIRK"=hex:25,02,6b,0e,c2,1a,f8,37,8c,c3,d0,d2,7a,f9,4a,6e
+"acbf71cef184"=hex:d8,97,cd,2f,7b,6c,ab,e2,12,62,c1,db,46,e5,b4,fe
+
+[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTHPORT\Parameters\Keys\1cc10c325f27\acbf71cef184]
+"LTK"=hex:ef,c1,03,0c,cb,d1,90,f1,61,14,b2,1a,52,45,11,ba
+"KeyLength"=dword:00000010
+"ERand"=hex(b):00,00,00,00,00,00,00,00
+"EDIV"=dword:00000000
+"IRK"=hex:1b,5a,69,12,cc,06,0b,23,91,ab,6f,e8,8c,fe,ba,7e
+"Address"=hex(b):84,f1,ce,71,bf,ac,00,00
+"AddressType"=dword:00000000
+"CEntralIRKStatus"=dword:00000001
+"AuthReq"=dword:00000020
+```
+
+We are interested in three lines:
+1. "acbf71cef184"=hex:
+2. "LTK"=hex: key
+3. "IRK"=hex: key
+
+We copy these three lines or the entire file to an usb stick or something else that can be accessed via Linux.
+
+We are done with Windwows so let's reboot back into Linux.
+
+### Phase 4: Transforming keys
+The keys from Windows are not applicable as themselves. We need to do some modifying to them. Don't worry. It's not too difficult. What we must do is:
+
+1. Remove commas
+2. Turn the entire string to uppercase
+
+```
+"acbf71cef184"=hex:d8,97,cd,2f,7b,6c,ab,e2,12,62,c1,db,46,e5,b4,fe
+becomes =>         D897CD2F7B6CABE21262C1DB46E5B4FE
+
+"LTK"=hex:ef,c1,03,0c,cb,d1,90,f1,61,14,b2,1a,52,45,11,ba
+becomes =>         EFC1030CCBD190F16114B21A524511BA
+
+"IRK"=hex:1b,5a,69,12,cc,06,0b,23,91,ab,6f,e8,8c,fe,ba,7e
+becomes =>         1B5A6912CC060B2391AB6FE88CFEBA7E
+```
+
+### Phase 5: Updating Linux configuration
+
+It is recommended to stop bluetooth service at this point.
+
+```
+systemctl stop bluetooth
+```
+
+Then we navigate to the *[BLUETOOTH ADAPTER MAC ADDRESS]* folder in our Linux bluetooth configuration.
+
+```
+cd /var/lib/bluetooth/[BLUETOOTH ADAPTER MAC ADDRESS]
+```
+
+Inside we will find folders for each bluetooth device similarly like in Windows registry. We make a copy of it as a backup 
+
+```
+cp -r [DEVICE MAC ADDRESS] [DEVICE MAC ADDRESS].orig
+```
+
+And then modify the `info` file inside *[DEVICE MAC ADDRESS]* folder. It should look something like this.
+
+```
+[General]
+Name=Bose QC Ultra Headphones
+Class=0x2c0404
+AddressType=static
+SupportedTechnologies=BR/EDR;LE;
+Trusted=true
+Blocked=false
+Services=...
+
+[DeviceID]
+Source=1
+Vendor=158
+Product=16486
+Version=340
+
+[LinkKey]
+Key=[KEY FROM PHASE 1]
+Type=7
+PINLength=0
+
+[IdentityResolvingKey]
+Key=[KEY FROM PHASE 1]
+
+[PeripheralLongTermKey]
+Key=[KEY FROM PHASE 1]
+Authenticated=2
+EncSize=16
+EDiv=0
+Rand=0
+
+[SlaveLongTermKey]
+Key=[KEY FROM PHASE 1]
+Authenticated=2
+EncSize=16
+EDiv=0
+Rand=0
+```
+
+Now we need to replace some keys with the one's modified a moment ago and here's how to use them:
+- The device key (D897CD2F7B6CABE21262C1DB46E5B4FE) goes to *[LinkKey]* section
+- IRK (1B5A6912CC060B2391AB6FE88CFEBA7E) goes to *[IdentityResolvingKey]* section
+- LTK (EFC1030CCBD190F16114B21A524511BA) goes to *[PeripheralLongTermKey]* and *[SlaveLongTermKey]* sections
+
+Like so:
+
+```
+[General]
+Name=Bose QC Ultra Headphones
+Class=0x2c0404
+AddressType=static
+SupportedTechnologies=BR/EDR;LE;
+Trusted=true
+Blocked=false
+Services=...
+
+[DeviceID]
+Source=1
+Vendor=158
+Product=16486
+Version=340
+
+[LinkKey]
+Key=D897CD2F7B6CABE21262C1DB46E5A4AF
+Type=7
+PINLength=0
+
+[IdentityResolvingKey]
+Key=1B5A6912CC060B2391AB6FE88CDADC7E
+
+[PeripheralLongTermKey]
+Key=EFC1030CCBD190F16114B21A527424BA
+Authenticated=2
+EncSize=16
+EDiv=0
+Rand=0
+
+[SlaveLongTermKey]
+Key=EFC1030CCBD190F16114B21A527424BA
+Authenticated=2
+EncSize=16
+EDiv=0
+Rand=0
+```
+
+We save the file and restart bluetooth service.
+
+```
+systemctl start bluetooth
+```
+
+Now the headphones should work both on Windows and Linux with no worries.