I occasionally update my web log, however updates are rare because writing ends up taking a lot of time. You have to identify an interesting topic, research it to fill the gaps needed to describe it, create a writeup with associated figures/pictures, edit it, and then commit to publishing it. Yes, it's entirely possible to create lower effort content, but it's substantially less satisfying to me.
Find a small project that you're interested in and check out the developmental discussion channels to see if there's any way you can lend a hand. Starting with trying to find complex coding tasks in large bureaucratic projects is setting yourself up for failure IMO.
For example, https://zynaddsubfx.sourceforge.io/contribute.html shows a few different levels of involvement in one project I maintain. That's not me saying you should work on this project specifically though; you'll want to find projects that you're enthusiastic to learn about.
Usually it takes a few days for the thread to completely populate, so unless you're looking at the rate that it fills up I think it's too early to decide.
No, I would not work on any personal projects during work hours as I don't want to risk any IP clauses getting applied to my own personal/side projects. Generally down time is a good opportunity to learn more about tools which could be applied in the future, but are not immediately required.
You're not (likely) going to be working casually on VLSI design, but for basic circuitry and embedded design you can work on hobby projects. I wouldn't compare that to having a fulltime job working on complex systems where you're going to be exposed to more elaborate challenges, but you can at least avoid letting hardware skills atrophy over time by using them for comparatively simple tasks.
If you want to have ragged starting information displaying pricing information for the various symbols in the range they're defined, I'd assume it's much more common that there's different start dates, but they're all defined for today. So, you could have a single checkbox to normalize based upon equal value at today's value and I'd default to having that on. As your baguette argument about the absolute values not having huge significance still applies it seems like it would work with no other modifications (i.e. it doesn't matter that it could require fractional shares and the like).
If the goal is to demonstrate relative performance over time, wouldn't it be useful to use a normalization such that all lines either start at the same point (e.g. simulating investing X amount) or ending at the same point (showing requirement to get to X final amount)?
Taking a quick look at the source it doesn't look too bad all things considered. First off, assume that there's going to be some sort of 32bit->64bit issues (likely casting pointers into 32bit words). So, start off on a 32bit setup, get things to cleanly build on -std=gnu99 (no need to cause yourself extra pain if it's optional). Then tidy things up with warnings (-Wall -Wextra on clang&gcc) such that the compiler can help you spot any existing bugs. Next up is the transition to 64bit. You're likely going to have to spot any pointer manipulation and where possible change 'int', 'long', etc into types which specify their length to make reading the code easier (subjective, but that's my opinion) e.g. uint32_t, uint64_t, etc. Then you ought to be pretty close to having all system tests pass on 32bit and the 64bit port.
I'd be worried if the code was old enough you were seeing K&R C notation or if it was a huge codebase, but it doesn't look like either case has occurred.
Of course if you're very much not a C programmer, learn some C. It's a comparatively small language overall (IMO) even if it's a low level one. Newer versions of the K&R book should get you up to speed pretty quick.
In what sense?
Linux has a number of ways of accessing the audio device, from the simple Open Sound System (OSS), to Advanced Linux Sound Architecture (ALSA), and Jack Audio Connection Kit (JACK).
JACK has become the most popular framework for nontrivial sound applications, but there is good support for the other interfaces as well.
There is also no major shortage of applications for either sound generation or analysis.
Compared to the applications listed, baudline provides a much more through analysis for instance.