Sebastian⚡ @sebastian@chaos.social

Introducing concurrency to solve any given set of problems, will result in a set of problems at least twice as large and they all occur concurrently in arbitrary combinations.

Going from student to working full time is weird. The weeks are much shorter now and I'm usually to tired to get much work done on my hobby projects during the week.
On the other hand I can suddenly afford the tools and parts to make really well engineered and professional looking stuff with very little effort.
After years of improvising with little to no budget, this feels actually surreal.

Knapp 25 Teilnehmer beim Amateurfunkkurs von DL0HSK.
Wenn jetzt noch min. die Hälfte bis zur Prüfung mitzieht wäre das schon echt genial.

@sebastian Non-Facebook Version: https://dl0hsk.de/chronik/2018-2/

Some spare parts and a few hours of work later the large FB53 beam at DL0XK is working again.

https://www.facebook.com/DL0HSK/photos/a.560639847722758/561486357638107/

If anyone hasn't seen it yet I'd really recommend you watch Scatt Manleys video where he does a really good postmortem with the engineering camera footage. https://www.youtube.com/watch?v=5boa6wAK0Sc

Okay could do a quick sed call and fix the name within my fork repo. However anything depending on the upstream package will have to modified as well. And looking at my dependency list that's a lot of stuff.

Aside from that I can't simply rebase my changes on the latest upstream to get bug fixes. So bad idea.

I've just tried to fork a go package, because I needed to some custom patching to it. (Nothing upstream would be interested, it might even break stuff, but works for what I need.)

Turns out that's a really bad idea, as the repo name doubles as package name. That didn't seem like a good choice to me when I first looked at go a few years ago. Well at least I know now why it felt problematic to me back then.