This is a sample newsletter. Sign up to get email delivery!

Hello there!

It’s been a while since you heard from me. I’ll tell you why, but first the news! There’s been quite a bit of news since we last talked, I’ll pick the top three stories:

NVIDIA Jetson AGX Thor

Jetson AGX Thor is on its way next month. Here are the specs and some images: https://www.nvidia.com/en-us/autonomous-machines/embedded-systems/jetson-thor/#dev-kit-specs

Physically it appears to be the size of the earlier Jetson AGX Orin internally, but next to the compute module is the cooling solution. The added fan appears to double the width of the footprint of the module itself. The power is configurable between 40W and 130W, so the extra cooling is needed to shoo those BTUs away.

There are some interesting claims, and the 128GB memory is certainly welcome. It should be fun to work with, as there are quite substantial architectural and system I/O changes coming.

We skipped over a NVIDIA chip generation leaping from the Orin to the Thor, so we should expect good things to happen. The introduction price appears to be $3499 USD, so this is directly aimed at people with serious applications and compute needs.

RealSense spins out of Intel

The RealSense camera group spun out of Intel, and raises $50 million. 

First off, you can tell they’re serious—the domain name (realsenseai.com) even has ‘AI’ in it! If you remember over the last few years, the way that Intel handled the RealSense handover was nearly comical. Most developers assumed that the cameras were discontinued, when in fact the product had only been sent over to another group within Intel. In a lot of ways, this should be better for developers. It can be difficult to act entrepreneurial in a large company. At the same time, RealSense raised some money so they should be able to keep developing the cameras.

Dustin Franklin

Dustin Franklin of NVIDIA has retired! Dusty was a developer evangelist for the Jetson, and I’m sure if you’ve used the Jetson at all you have used his work. He led the community Jetson AI Research Lab and wrote jetson-containers. The Jetson community owes a lot to Dusty, and we certainly appreciate his efforts.

I’ll tell you a quick story. Back in early 2015 I went up to NVIDIA to talk about the Jetson. At the time, Dusty was working at General Electric. During one of the meetings, a couple of NVIDIA folks told me excitedly that they were going to hire Dusty! Just like you can get a dog all excited by acting excited yourself, I was all enthusiastic too! I may have deflated the balloon a little when I excitedly asked, “Who’s Dusty?”

Over the next 10 years we worked quite a bit together. We did videos, and interviews on the NVIDIA YouTube channel. We also did some Deep Learning Institute (DLI) videos. He is one of the main Jetson Open Source advocates, and I always appreciate someone as smart and articulate as Dusty. While he will be missed in that role, he ain’t dead. I look forward to our paths crossing again in the future.

If you’ve wondered why I’ve been quiet lately, it’s because I’ve been working on improving the web experience for JetsonHacks. There are different components I will be rolling out over time. The first is a feature I call “Video Storyboards”. This allows combining video with synchronized text and media. This is Stage I, with more features to add. These are intended to work on desktop machines, preferably with 4K monitors or better.

Here are a couple of examples. The first is an interview by Cleo Abrams of Jensen Huang

The second is a very good talk by Andrej Karpathy.

You’ll have to tell me what you think.

I went down a bit of a rabbit hole building these, which consumed all of my attention. Now that I’m nearing completion, you should start seeing more regular content again.

On Software Stability

Over the last few months, we have seen major parts of the Jetson operating system cause significant problems. A few months ago, an upgrade to Docker resulted in previously working containers becoming unable to launch. A couple of weeks ago, an upgrade to Snap, the Ubuntu package manager and app launcher, prevented many applications from launching.

In both cases, updates provided by groups outside of NVIDIA rendered the Jetson unusable for many common tasks. This raises important questions: Should we auto-update our software? How much responsibility lies with NVIDIA versus the broader Jetson ecosystem?

If you are an experienced developer, you know that auto-updating your development system is usually a bad idea. Every professional development team maintains an “approved” operating environment. Larger companies have strict policies about what software can be installed, and precisely when and how machines are upgraded. This is especially true for development environments, particularly in embedded systems.

Even security patches must undergo at least minimal testing before deployment.

Then the question arises: “If large companies manage their projects like that, why don’t individuals do the same?” There are several reasons.

The first is that most individuals don’t have the meticulous maintenance habits of a corporate system administrator. Often this is simply because they have other responsibilities—such as having a life—to attend to.

The second reason is that many people enjoy having the “latest and greatest,” even if there may be pain associated with being at the forefront. While most don’t utilize new operating system features, the desire to have them remains strong.

A third reason is that some people simply don’t know better. By ‘experienced developer,’ we mean someone who has been bitten by bugs and issues so often that they instinctively recognize pitfalls and actively avoid them.

What experienced developers do is lock down their development environments as tightly as possible. If updates occur during a project, they delay applying them until as late as practical. There might be a critical fix in an update—but if that fix doesn’t affect their project directly, seasoned developers wait.

I’m sure you’re familiar with Eric S. Raymond’s 1999 book, ‘The Cathedral and the Bazaar’. Here’s the thing: If your company delivers an operating system, you’d better ship something stable. When you update that system, you bear the responsibility.

You can ask Microsoft or Apple about that. You don’t want villagers coming after you with pitchforks.

On the other hand, consider Linux. There’s a guard at the kernel gate because Linus Torvalds oversees contributions. However, the GNU utilities and the rest of the system are rather ad hoc.

The original idea behind Unix was that the kernel and accompanying programs are “little gems of code”—elegant, concise, and meaningful. They represented the pinnacle of computing.

That might have been true in the days when Thompson and Ritchie invented Unix. After all, they were quite clever. They packed substantial functionality into just 56KB of memory on their PDP-11/20. You read that right: the operating system and applications had to fit into just 56 * 1024 bytes.

Here in 2025, developers have slightly more memory to work with. Countless contributors enhance the Linux kernel and GNU utilities, providing many gems. Yet, as time goes on, let’s say that less than stellar contributions sneak in.

Open-source “free software” attracts many developers. Continuous improvement means each gem is frequently polished. Among developers, those who say “let’s remove some features” are quite rare. Instead, developers tend to add new functionality.

Each developer has their own idea of what “better” means. Take Docker 28.X as an example. Docker isn’t an individual contributor; it’s a company investing resources to push their product development forward.

One important Docker customer segment is server farms. Time is money, and security matters immensely. Profiling revealed potential time savings by improving network stack efficiency—great news! After implementation, Docker utilized `iptables` in the Linux kernel to achieve these gains.

However, Jetson’s default Linux kernel lacked the necessary modules to support these changes. After flashing or upgrading Jetson Linux, Docker’s new version installs, but containers fail to launch due to this incompatibility.

This problem compounds across individually maintained packages. Developers strive to improve their software, yet what is “better” to them might be irrelevant to average Jetson users. An edge device sees little benefit from a faster Docker network stack or finer permission controls in Snap—but these updates broke Jetson Linux nonetheless.

I’ve long viewed updates as potential threat vectors, especially on work machines. For major operating system revisions, I prefer getting a new machine altogether. Though setting up a new environment and migrating data is painful, it’s the only reliable method to ensure a stable configuration for comparison. Major point releases bring disruption, which complicate straightforward transfers.

This issue is further muddied by what started as Google’s “perpetual beta” trend. Conceptually, Google needed only to update their servers, allowing frequent deployments with the fallback excuse, “the software is beta.” This initially worked well. Unfortunately, it permeated software culture to the point where many companies now ship inadequately tested products.

So, what can you do to protect yourself? The principles haven’t changed since Unix’s creation. Maintain regular backups, ensuring you can revert to a known stable state. Use modern version control tools to adopt a more granular backup strategy.

You must decide whether to enable automatic updates. If behind a secure firewall on a local network, disabling auto-updates can be relatively safe. If exposed to the open internet, aggressively apply security updates to remain protected.

When planning projects, my rule of thumb is to expect one lost day in a ten-day development cycle. Issues inevitably arise; sometimes they’re the developer’s fault, sometimes they’re beyond control. With looming deadlines, plan for two lost days out of ten—people generally don’t respond well under pressure.

Quick Takeaways:

– Avoid automatic updates on critical development systems.

– Delay major updates until essential or near project completion.

– Always maintain regular backups and use version control.

– Allocate buffer days in your development cycle to handle unexpected issues.