Getting off-topic, but as a successful high-school dropout I am compelled to remind anyone reading this that [the American] college [system] is a scam.
That's not to say that there aren't benefits to tertiary education, for many people in different contexts. It's just not the golden path that it's made out to be.
Many people currently in college are just wasting their money and should enroll in trades programs instead.
Meanwhile, nothing about being in or out of school is mutually exclusive to using LLMs as a force multiplier for learning - or solving math problems, apparently.
I would love to better understand how a device launched the year before I was born could be so flexible in its configuration and operation. I can't update the code running on a microcontroller on my desk in front of me without it triggering a reboot.
When they talk about rerouting power and performing a "big bang" reconfiguration with a 23 hour lag on equipment that was underpowered when the 8088 came out... it kind of melts my brain.
Apparently it still has ten years worth of fuel left!
NASA pioneered a lot of what underpins modern design of critical computer systems. Voyager's systems are impressively robust. As far as I know, they can patch it by directly sending up new assembly instructions that are written into its memory, and doing a warm reboot to get it to start executing new instructions without powering down anything. They had the foresight to make their software highly editable, while also having multiple redundancy and emergency systems. Despite this, I wonder how much pressure the people writing this software feel. Even with all the simulators and months of rigorous testing, sending up something that can (in the worst case) break the probe has to be terrifying.
I second your recommendation. I watched it last night, and loved it. It was beautiful to see the level of competence and devotion of the tiny group running the spacecraft.
Here's a talk about how the Voyager team fixed the flight data computer on Voyager 1 when a memory chip went bad on it a few years ago. It goes over how the flight computer works and he walks through a few assembly routines. https://www.youtube.com/watch?v=YcUycQoz0zg
Some of the challenges they had to deal with while developing the fix:
- The only source code they had for the flight data software was an OCR'd Microsoft Word document (with typos) that was likely scanned from a hard copy assembler listing printout.
- The processor runs a custom instruction set developed by JPL for the Voyager mission. The documentation they had on the processor was incomplete.
- Everybody who had designed the flight software was dead.
- They had no assembler, no debugger, and no processor simulator. They had no testbed, the only two FDS processors were in space.
The 2025 YouTube video is "How We Diagnosed and Fixed the 2023 Voyager 1 Anomaly from 15 Billion Miles Away" by David Cummings of JPL.
There is a Vimeo video of the Voyager team reacting when data first began trickling in from Voyager 1 after the fix in April 2024. "Voyager 1 Team Reacts to Receiving Engineering Data From Spacecraft" (JPLraw channel): https://vimeo.com/939376171
Cummings is the one against the back wall who shoots his two arms up in the air in celebration. He and Armen Arslanian (in the blue shirt to his left, right in the image) developed the software fix.
> microcontroller on my desk in front of me without it triggering a reboot
Most microcontrollers can update their own flash while running, either with a built-in bootloader or a user-programmed bootloader that takes up a little bit of the flash.
What makes you think that Voyager isn't "rebooted" though?
This kind of update is often kind of ass to do, though, because you may not be able to execute from said flash while you’re updating it.
So you copy a small write routine into RAM, copy a chunk of new data there too, jump to the routine, then it returns to your main bootloader in flash which receives the next chunk from a UART or whatever (because of course it doesn’t fit into RAM all at once), rinse and repeat. You aren’t exactly going to be serving realtime interrupts during this.
(So if you do need minimal downtime, you probably have dual external flash chips, or even just two microcontrollers given execute-from-external-flash would bump you up to fancy micros.)
With sufficient motivation and effort, you could have a self-updating microcontroller. You could, if you really wanted to, write firmware just as robust, reliable, and flexible as the Voyager system.
It's just that in most cases, the amount of effort required is orders of magnitude higher than is really justifiable.
It's a real shame that people bought into this false dichotomy, because the base reality is that people who work in web dev that stubbornly pick either code or layout are more of a liability than an asset.
I don't believe that people who can design and code are as rare as folks seem to believe, either. What seems more likely is that there are a LOT of coders who are extremely fluent in CSS but aren't particularly gifted when it comes to making things look good.
It wasn't that long ago that designers understood that they couldn't just hand off a 2D comp of what they want to see. The job isn't done until the output can be integrated into the app. Nobody gets to launch cows over the wall and go for lunch.
Honestly, I never understood the move to create an artificial dichotomy between design and code with a heavy layer of tooling.
I suppose that a layout engine made sense in the context of Flash, and you saw the future of the web as a set of keyframe animations. But the notion that there's a lot of value in creating a very heavy, high-friction abstraction between the UI/UX and the platform it ultimately runs on was always going to be a loser.
In the end, it turns out we're all just web developers, regardless of your weapon of choice.
The addition of frameworks like Qt and yes, web wrappers certainly complicates things unless you're presumably deep in it.
What isn't clear to me is whether Win32 is still technically a viable choice for "modern" Windows 10/11 development. In other words, could you submit a Win32 app to the Microsoft Store, if that was something you felt like doing?
> What isn't clear to me is whether Win32 is still technically a viable choice for "modern" Windows 10/11 development. In other words, could you submit a Win32 app to the Microsoft Store, if that was something you felt like doing?
I believe so, although originally the store required other toolkits, they changed thier mind.
That said, I don't think it's very important for windows programs to come from the microsoft store... the limitations are not worth the market, especially since the store is unreliable: at least in my experience, the installation can get messed up and it won't self repair, and then you can't install new software... Why would you want to support that, when you could just provide a downloadable installer and license keys? (And tell people the sequence to escape store only mode)
Don't get me wrong; I absolutely refuse to use the store.
I'm just not deep enough in this to know the correct terminology. What I think I'm trying to ask is whether Win32 is still considered viable / equal opportunity compared to something built with, for example, WinForms. (To pick a name I remember.)
From the outside, all of this churn makes me completely understand why web wrappers are so popular.
Yes, because anything WinRT has been messed up, it was going well between Windows 8 and Project Reunion, as it was progressively getting feature parity with Win32, then everything went downhill and you can safely ignore anything from Microsoft marketing related to WinUI/WinAppSDK.
It was so bad that on BUILD 2024, WPF regained its official status out of deprecation.
So, Win32 (+ COM, most new APIs since Vista are COM based), Forms, and WPF, or oldie MFC, if on Microsoft own stacks.
Otherwise Delphi, FreePascal, C++ Builder, Qt, Avalonia, Uno if going 3rd party.
Don't get me wrong; I actually appreciate the breakdown. It just makes me not want to even consider native Windows development. This is definitely an example of too many choices being a very bad thing.
This reply stuck in my head and bothered me enough that I am back several days later to tell you about it.
First, blaming this on developers is simply a bad take. Developing a native app shouldn't be a purity test. Electron and friends clearly offer a path of least resistance, even if it is deeply flawed. The decision to use it and accept the tradeoffs is just as pragmatic for the solo greenfield dev as it is for the many who are told by their employer to use the cheapest, fastest option.
No, if there is a fault, it is squarely on the shoulders of Microsoft for not successfully executing and sticking to their promises. Developers and companies are effectively investing in Microsoft's integrity when they decide to accept that the latest framework is truly the final form, and they've been let down over and over by them.
Second, defending the state of development on Windows as fine because everyone else is doing it is just... kind of lazy while being totally irrelevant to the larger question of how to develop native apps on Windows.
I'm annoyed because this comment really and truly feels like an example of why we can't have nice things.
reply