On one hand, it seems rather strange, because back in the early days of C (and later C++) there were far more CPU architectures in play. Every big Unix hardware vendor had their own CPU architecture, whereas today we only have about six. (In my mind: x86, arm, mips, risc-v, ppc, and s390x)

But it might be that in the early days of C/C++, development involved connecting to large shared Unix environments where the machine you developed on what always the machine (or at least the same type of machine) the program would run on, and also that those vendors weren't exactly incentivized to make developing for competitor's architectures easy.

I have an even stronger sentiment regarding cross compilation though - In any build system, I think the distinction between “cross” and “non-cross” compilation is an anti-pattern.

Always design build systems assuming cross compilation. It hurts nothing if it just so happens that your host and target platform/architecture end up being the same, and saves you everything down the line if you need to also build binaries for something else.

If I were more money motivated I’d probably be building CRUD apps too. I just like weird puzzles XD.

It really opened my eyes to just how food centric society is.

I am a big guy (6’4, 330 lbs), but I was amazed that Ozempic just seemed to do nothing. I was having the gastric side effects, but I could still eat 3000 calories a day if I cheated without feeling anything.

But I feel you on sugar. Took me a long time to cut sugar cravings. A decade ago I cut regular soda out of my diet, which a few years later led to me cutting out pretty much anything sweetened. Realistically it wasn’t the sweetness for me, it was the “mouthfeel” or doing something with your mouth. Just straight sparkling water satisfied the entire craving for me.

The hardest thing for me to give up / heavily cut back on was fried things. Maybe that’s the result of my parents using french fries as the reward food when I was a kid…

Decided to try Ozempic and was on it for about 6 months. Didn’t do a single thing for my appetite unfortunately, even on the max dose.

Sample size of one here, but if you’ve got mental health struggles that feed into your eating patterns, GLP-1s might not help with your weight problems.

Sure we’ve had the ability to keep the pipeline on GPU for awhile, but it usually required platform specific API bindings to convert to a platform specific descriptor (handles on windows, IOSurface on macOS, dmabuf on Linux), which you then had to pull into a platform specific decoder/encoder API (DXGI, WMF, AVFoundation, VAAPI, etc.), and then all of that again but in reverse to get the surface back into your 3D API.

This whole thing just makes life easier for everyone.

JACK doesn’t support device hotplug (ya know, connecting and disconnecting a headset, something most of us do) and it also doesn’t support multiple applications generating audio without the user having to configure how audio is mixed.

JACK is designed for low latency in environments like Digital Audio Workstations (DAW) where you know 1) what audio hardware is present at all times, and 2) what applications are going to generate audio.

Many people who use/used JACK ran a PulseAudio bridge on top of it for every application that wasn’t the one or two applications that needed ultra low latency audio.

PulseAudio had some major warts, but JACK wasn’t some panacea that did everything better.

Regardless of how you feel about Wayland, its creation set off _massive_ improvements across the entire Linux graphics stack.

For those of us who were using Linux on the desktop in decades past, remember when you couldn't use a GPU without X running? Remember the days when you needed an X session running in order to use CUDA or OpenCL? Remember the days when the entire graphics driver lived inside of X? When display server issues caused kernel panics? Remember the days when you couldn't share a hardware graphics surface between processes? When it was impossible to get hardware acceleration to work offscreen?

Wayland's aggressive stance on "it doesn't work on platforms that don't fix all of that" is one of the only things that pushed the stability and flexibility of the graphics stack on Linux forward.

I don't really think anything less than saying "We the X developers are going to stop X development and X is going away" would have been enough to push graphics card vendors to actually rework the drivers.

Makes doing things larger than 8/16 bit computers very complicated and usually very slow :(

The problem is not that gaming GPUs are in demand, it’s that selling silicon to AI center buildouts is so absurdly profitable right now they just aren’t making many gaming GPUs.

If you can only get so many mm^2 of dies from TSMC, might as well make 50x selling to AI providers.

> [1] This story requires some reading between the lines - the exact text of the contract isn’t available - but something like it is suggested by the way both sides have been presenting the negotiations.

I deal with far too many people who won't believe me without 10 bullet-proof sources but get very angry with me if I won't take their word without a source :(

It was like pulling teeth trying to explain to someone that they couldn’t use the Linux GPIO subsystem from python to accurately measure sub-millisecond events…

Linux is a general purpose OS, it’s typically tuned for throughput not precise timing. Sure there’s PREMPT_RT but it only buys you so much.

Even if your "self hosting" is renting a $5/month VPS, some spam lists (e.g. UCEPROTECT) proactively mark any IP ranges owned by consumer ISPs and VPS hosting as potential spam. I figured paying fastmail $30/yr was worth never having to worry about it.