Forem: Lee Carver

Putting Codex To Task

Lee Carver — Fri, 28 Nov 2025 20:46:46 +0000

I’ve been putting OpenAI’s Codex coding assistant to task. Literally.

Codex and I put together a task management system for the open source application DepanFx. The launch customer for these features was asynchronous file loading, a point of notable lag. The new capabilities avoid locking the UX loop, and provide an acceptable UX for notification and tracking of task execution. Before we were done, asynchronous file loading was also added to the session startup execution path.

With Codex’s help, I was able to add asynchronous file loading, with robust task management support, in roughly 4 days. All in, including a few more days of expanded functionality and other cleanup, Codex and I were able to bring up almost four thousand lines of new task management software.

This development felt roughly twice as quick as a fully manual implementation. Codex’s production of routine boilerplate software was a boon, with over 3,000 lines of working code in one day. It correctly handled many of the known nuances in multi-threaded code (e.g. InterruptedException).

Codex also required close supervision. Like a freshman intern, Codex is eager to make things work with a tendency to over-engineer its poor encapsulation. Wisdom provides guidance on whether these faults can be reworked or whether the goals should be revised. Wisdom is not Codex’s strength.

Working With Codex

Sitting down at the start of a major project to write down the goals and a plan for that effort is standard practice for good software engineering. Working on my own, I can shrug off the spec and let the implementation and the context drive the result. This is a poor strategy for AI.

Even more than humans, AI systems need a specification in order to be successful. As others advise, getting any AI system to generate the desired results requires clarity and detail in the prompt. Despite this good, creating that specification prompt does change that pace of discovery during software development.

After submitting the prompt and waiting out the response, I often find it hard to accept Codex’s proposals directly. I tend to integrate the Codex changes into a development branch that I control. If a set of changes is mostly sound, my process is roughly these steps.

Have Codex push the changes to git as a PR.
Fetch the PR’s branch via git
Merge the Codex branch into the development branch
Edit and refine until everything is fine.

If the proposals are more like “interesting” ideas, it is often easiest to cut and paste the good parts into the evolving branch. It tends to be the fastest way to get the good parts into production.

A Journey of a Thousand Steps

Getting Codex to produce acceptable code was quite a journey.

I took about an hour, including some ChatGPT questions, to assemble the design considerations into a 2 page document. One of the key elements in the prompt was the specification that implementation should proceed incrementally.

The initial Codex PR provided a reasonably sounded Java module for handling tasks. The implementation was well done, if overly complex. Tasks would get assigned a UUID, but there was no need. The task executor was implemented as a large file with multiple member classes. Pulling this apart made the structure much more evident. Despite the rework, it was still just a few hours for over 800 lines of solid task management capabilities.

Next up was a module for user interactions with these tasks. The incremental process led to one set of changes for the new module, another for a generic data model, then one for a popup window, and final one for a more detailed panel. Codex handled the tedious details of binding UI views and data sources, providing a rich user interface for control of asynchronous tasks.

Overall, Codex helped me knock out over 3,000 lines of code in one day. This was green-field code. Codex was a great boon for generating the hundreds of lines of routine definitions that are common in user interface components.

The challenge was the new code had zero interactions with the existing system.

Adding Asynchronous Tasks

Moving any application from a single threaded model to a multi-threaded model is a challenging endeavor.

Codex failed on this with its initial try. There was duplicated code splattered everywhere. It was confused by separate open and load paths. Some experimentation clarified that the handling of resource loading and their display were too closely entwined. This coupling of resource loading with resource display left no room to make the resource loading part of an asynchronous task.

Separating these tasks into distinct operations had been a known but tolerable code smell. With the advent of asynchronous loading, restructuring to clear that smell became essential.

However, this was not a task for AI. Finding a solution required experimentation with the existing data structures. At its core, the restructuring involved a subtle rearrangement of responsibilities, with some widespread changes to the declaration of built-in resources.

I suspect that Codex would have done fine if I’d told it which restructuring to perform, but that required experimentation and discovery of the desired restructuring. I have little confidence that it would have found a clean refactoring on its own. In the end, smart code completion from my IDE was the biggest aid to completing this restructuring work.

Away We Go

With the code restructured to enable asynchronous loading (and a more specific prompt), Codex proposed a clean software structure for loading files asynchronously.

Each module that interacts with the task monitor module introduces a task package that encapsulates asynchronous task management.
The task package contains a ModuleServer class as a component. This class handles all interactions between the module's components and the task monitor module.
The task package contains process related Task classes. These implement the task control API defined by the task monitor module.
Each unique interaction with asynchronous tasks is a call to a service method in the ModuleServer class. This method provides the shared logic for creating and managing an asynchronous task.

This architecture worked well, and has good scalability aspects. It was straightforward to extend this model to session startup.

Coasting to Completion

With asynchronous file loading a success, the original goal had been achieved. DepanFx was able to open large files without stalling the UX, and it automatically displayed a task monitor window when an asynchronous task was active.

The final changes before declaring success were quite limited. There were a few tweaks and adjustments in the layout of items for task rendering. It was a good chance to put on some final finishes.

The asynchronous loading of content files was extended to the session files. This is a boon to the application’s apparent startup time. The pattern of a ModuleService class was easy to extend into the new use case.

The popup for a new active asynchronous task was distracting, especially for very short tasks. The UX was much improved with a short delay before rendering the monitor dialog.

Most of this was cut and copy or small manual tweaks without Codex assistance.

Conclusion

TLDR: Codex was a real benefit to implementing a task manager for DepanFx.

Strengths: On green-field development, Codex does well. It often needed minor rework to better align with project naming conventions (e.g. DefaultExecutor versus SimpleExecutor). It correctly handled some parts of tricky multi-tasking code, such as including the oft-forgotten handlers for InterruptedException.

Challenges: Codex is happy to blunder forward when a step backward to refactor is more appropriate. The addition of multi-tasking into a single threaded application emphasized the need for the cleanup of existing code.

So in the end, it was what we all know.

AI code generation can be a productivity aide, especially with routine or well understood behaviors.
It has tendencies toward overly complex solutions.
It has tendencies towards poor encapsulation.
With poorly organized code, you’re likely to get unsavory suggestions.

Regardless, journey forth, and trust but verify.

Modules, and Java, and Windows, Oh My!

Lee Carver — Wed, 22 Oct 2025 18:52:47 +0000

I get that desktop applications are out of style these days. But they are still a good way to deliver powerful features and high performance graphics.

However, delivering modular Java applications on Windows is a challenge. It almost seems like Java and Windows have conspired against each other. Java requires that all module jars are listed in one command line parameter. That works fine when Unix shells have a >100K character command line. Windows batch files have a relatively short limit (8191) on the lengths of their command lines. This makes it impossible to launch large-ish modular Java applications on Windows using the standard scripting model of every parameter on the JVM’s launch command line.

The work around is to specify an argument file (e.g. @app.args) when launching Java. Building that argument file takes a trick or two. You can jump ahead and see the full solution for DepanFX at commit 19435687 Customize command script for Windows ….

Problem Statement

The DepanFX application provides visual tools for analyzing large programs. It is written in Java, and its architecture adheres to the structures of the Java Platform Module System (JPMS). It's structure is typical of medium to large modular Java applications. It depends on a large number of external libraries,
and many of these components must be listed on the module path when
the Java JVM is started.

When any modular Java application is launched, the Java JVM requires that the --module-path argument is followed by a list of all of the module jars.
It’s easy to have dozens of modules, so that module path list argument very quickly gets to be very long.

20 characters per jar file name * 80 module jars = 1600 characters

Not too bad, but the absolute installation path can easily add 80 characters per module entry.

80 path characters per module jar * 80 module jars = 6400 characters
Total characters per module file = 8000 characters.

All of the sudden, the command line is up against the Windows command line length limit. Many of the remaining 191 characters get taken up by the Java launch command, required command flags, and the application's classname, and required punctuation. Conventional launch scripts crash when this happens.

The Workaround

As Microsoft so blithely advises:

To work around the limitation …. Modify programs that require long command lines so that they use a file that contains the parameter information, and then include the name of the file in the command line.

Despite the inherent complexity of this suggestion, Java has implemented an argument file mechanism for long parameters. All that is required is to write the arguments into a temporary file and replace them on the command line with an @app.args on the command line argument.

Revising the Launch Script

One of the first challenges is that the Windows launch script is a generated artifact. Like many applications, DepanFX’s overall compile, assemble, and publish processes are coordinated by Gradle.

The Gradle application plugin handles construction of the launch scripts for both Unix-like and Windows operating systems. The Unix scripts assume a POSIX-ish platform is available to /bin/sh scripts. The default Windows script follows a similar functional pattern. These start scripts:

Establish the APP_HOME variable as the base for the installation.
Confirm or discover the path for the Java command.
Run Java with all the parameters required to execute the application.

For both Unix and Windows, running Java includes setting a number of environment variables that are used in the launch command. If all the options are stuffed into a temporary file, none of those environment variables will be necessary.

Both of the launch scripts are configured using replaceable templates. The Windows specific template can be replaced by adding the following snippet to the application’s build.gradle file:

tasks.named("startScripts") {
  windowsStartScriptGenerator.template =
     resources.text.fromFile('gradle\\customWindowsStartScript.txt')
}

With this in place, Gradle will build the application’s Window launch script using the customized start template instead of the build-in template.

The text of the built-in template is available via github as windowsStartScript.txt in the plugins-application subproject. It’s a great place to start, with Windows specific commands to configure APP_HOME and to establish a viable JAVA_EXE. These can be left as is.

The sections that configure Java related environment variables need to be converted to write these values to a temporary file. The environment variables are only used in the Java launch command, and that is being converted to use the temporary file.

Instead of one line setting an environment variable to a potentially very long template supplied value:

set MODULE_PATH=$modulePath

The new template file writes a separate line to the launch script for each element of the module path. Each batch file line will append the full path name of an installed module to the argument file.

>>"%ARG_SPEC%" echo --module-path
<% for (moduleEntry in modulePath.split(';')) {
  %>echo "${moduleEntry}" >>"%ARG_SPEC%"
<%
}%>

The full set of changes to capture all the Java launch parameter as an argument file are visible at depanWindowsStartScript.txt lines 76 to 96.

With all the Gradle specified options moved from the command line into an arguments file, it should be straightforward to launch the Java application with the following Windows command line

"%JAVA_EXE%" @"%ARG_FILE%" %*

This will start the Java JVM ("%JAVA_EXE%") using the arguments in the argument file (@"%ARG_FILE%") and any command line arguments provided by the user (%*).

Unfortunately, this doesn’t work. The arguments written by Windows are in the wrong format. Most importantly, path names for the modules are saved as Windows filenames, with single back-slashes ("\"). Additionally, multi-line parameters don’t have the correct end of line terminators.

Converting the Argument File

On Unix platforms with a normal shell (/bin/sh) and $PATH, these kinds of corrections can be handled with common text editing tools like sed. None of these tools for manipulating text are available in a vanilla Windows installation.

The one extended resource that is available is the Java JVM, available at "%JAVA_EXE%". With the addition of a very small Java application, it’s straightforward to rewrite the Java launch specification file written by the launch script into a launch argument file that does comply with Java’s rules for backslash encoding and other argument rules.

Simply run this before running the intended application, and all the arguments are provided to the Java JVM in a manner that works for Windows.

"%JAVA_EXE%" -cp "%APP_HOME%\\lib\\DepanFxLauncher.jar" com.pnambic.depanfx.launcher.DepanFxArgFile "%ARG_SPEC%" "%ARG_FILE%"

The main class DepanFxArgFile runs to just under 200 lines of text, including whitespace and comments. The whole jar file is under 7KB. It reads a launch spec file from the supplied filename, and writes a Java argument file to the second filename. The transformations are simple, but include:

backslash escaping
separating multi-argument lines into individual lines
concatenation of --module-path and --classPath

Adding the launcher project to the application project as a runtime dependency ensures that Gradle’s application builder places the DepanFxLauncher.jar in the expected %APP_HOME%\lib directory.

All Together Now

The entire set of changes for DepanFX is encapsulated in commit 19435687 Customize command script for Windows ….

This commit modifies the Gradle generated Windows launch script with these changes:

Add the Gradle launcher project, with the DepanFxLauncher.jar artifact.
Use the launcher project as a runtime dependency for the application.
Set the Gradle template for the Windows script to be customized for the project.
Revise the Windows start script template to create a launch specification from the template values.
Add the transform of the launch specification into a Java argument file.
Adapt the application launch to use the generated argument file.

With these changes in place, it appears that Gradle’s application plugin can continue its happy role as the packager of choice for DepanFx.

Perhaps these notes will show a path forward for your modular Java desktop applications.

Confessions of a Big Screen Bigot

Lee Carver — Mon, 22 Sep 2025 18:37:06 +0000

Hi. I'm Lee. I am a big screen bigot.

For decades, I wanted more and more screen space. I now have a setup for my desktop work that fills my visual field. Some incremental improvements would be nice, but it’s hard to do a lot better. I’m constantly amazed at people who seem to live their entire lives through a 6.1 inch diagonal screen.

We’re Only Human

Large format high quality computer monitors are not cheap. It would be good to have some objective basis for these expenses. We also know that the people with the least experience think they are the experts. Some objective information from human factor research can help avoid the worst of biases.

Some of these observations come from past reading. Some are easily confirmed with an Internet search. Some of these are purely anecdotal, based on my own experiences. Regardless, I’m able to use them as a sound basis to justify the results I like.

Observations About Human Vision

For best results, we want a display system that works well with human vision. Human vision has a few idiosyncrasies, and working with these gives the best results.

The human eye has a total visual field of about 200° horizontal and 135° vertical.° But this is not uniform. Because of the nose, only the central 120° is binocular.

High resolution foveal vision is much narrower, but our brains trick us into a full visual field. The effective resolution of the human eye is about 1 arcminute, or 60 pixels per degree.

Our eyes do not scan this space uniformly. The way ChatCPT put it was “vision-science people [know]: our vertical eye movement range is more comfortable and broader than horizontal scanning, which often needs head motion once you get past a certain lateral extent.” Its primary citation even exists.

Another concern with very large screens is the varying distance of your eye from the screen. With a flat panel screen, my eyes will be 21” from the center and 30” from the edges. Especially at that close range, I feel my eyes refocusing to handle the 9” change in distance (+42% change).

Observations About Problem Solving

People can’t really multi-task.

At best, you can have some good task switching habits.

Immersive focus is an essential part of creative and knowledge based tasks. For software engineering, I want to see all of the data and all the code possible. I want to be able to fill my visual field with information to better understand their relationships.

If you do need to take a break, it’s best to leave everything in place. If stuff needs to be put away, with the next task to be unpacked, it is hard to be productive.

Multiple desktops provide a way to leave most of your interrupted computer work in an idle state.

History

I’ve been trying to write software since I discovered it was a thing.

In the early 1970’s, it was hard to make anything happen. Pencil and paper concepts were about as good as I could manage. But I was there as a user as our modern video systems developed.

Very early on, I got to use an IBM 5100 to write some APL programs. It had a 5 inch display offering 16 lines with 64 characters. I also used punch cards and teletypes. Mostly, you looked at printouts. I drank the koolaid that was available.

With the early 80’s and into the PC era, the 13 inch monochrome monitor was becoming standard. EGA was just beginning. Technical support for video monitors was minimal. X11 comes later in the decade and Windows 3.0 starts the next decade.

In the late 1980, I got a job at Boeing Aerospace. We were developing some software engineering tools, and I get this “huge” 21 inch grey-scale monitor. It is a revelation. I can see an entire page of text on the screen, so the compromise with printing out the code to review it has changed.

In 1990, I moved to another Seattle technology company. It took me a while to get back to being comfortable with their PC grade monitors. Even with color XGA, a 14 inch screen is small.

Fortunately, video standards were advancing, with EGA becoming VGA, XGA, and DVI. At one point, I had two 20 inch CRT monitors on a desk. It took two desktop computers and a sturdy desk to make it work, but I loved the productivity boost from all the screen real estate.

In 2004, I joined Google. Thanks to enlightened senior management, all software engineers got two 24 inch flat screen monitors connected to a powerful Linux workstation. This was another revelation about what is possible with video systems. A single desktop that spanned the screens was wonderful, compared to two separate screens. This koolaid was much better.

For several years, this was pretty much everyone’s standard. The screens got incrementally bigger. By 2014, dual 27 inch monitors were conventional at better development companies. I kept mine slanted, at a V, to reduce the variation in distance across my visual field.

Dual horizontal monitors were the widespread convention when I noticed a junior engineer put one monitor vertical and the other vertical. Another revelation. He used the vertical monitor for coding tasks, and the horizontal monitor for other daily tasks.

Amazing as it was, my mind leapt forward with possibilities. I’d seen Google’s Holodeck, with a wall of vertical monitors arranged to surround you. Using dozens of monitors would be out of reach, but three vertical monitors fills your vision if you sit in one place.

What I Have Now

The opening image, repeated here, captures the basic configuration.

What you see are 3 Dell UltraSharp 27” monitors set up vertically, arranged in a soft curve. The curve follows a 21 inch radius centered at my chair. This minimizes the need to refocus as my eyes scan across the visual field.

These are the 2016 version, with 2560x1440 resolution (QHD). It’s a lot more bits than 2K (2048x1080), but not the 4K (3840x2160) we get today. The effective screen size is 4320x2560, just under what Tom’s Hardware calls a 5K resolution (5120x2880).

Some math says the screens fill about 110° horizontally and 55° vertically. The human eye’s resolution is roughly 60 pixels per degree or a potential of 6600x3300 receptor pixels. More math says the screens have more than 50% of the potentially viewable pixels.

For reference, a 12 inch laptop screen that is sitting on a desk 21 inches away fills only 17° horizontally and 16° vertically. These three 27 inch screens fill everything except my peripheral vision.

Although this arrangement is sometimes awkward with spreadsheets and those applications that insist on being wide, it is great for looking at code. Physically, each screen has roughly the same number of square inches as three sheets of 8.5x11 paper. It’s possible to display over 1,000 lines of code on these screens.

How To Use It

As delightful as I find this three monitor system, there are some practical considerations.

The first consideration is a computer system that supports triple monitors. This has been a requirement of all of my workstations. Many laptops will drive three monitors, preferably with the minimum number of adapters.

When I first configured a system with triple monitors, I could not get to all of the information fast enough. My rapid head swivels from left to right and reverse led to a few trips to the chiropractor.

Perhaps I could have developed neck strength. I did learn to slow down slightly on horizontal scanning in either direction. I also learned to organize my workspaces with vertical data for easy vertical scanning.

Regardless of the number of monitors, multiple desktops are an essential component of my work. The screens serve as one desktop, slightly ignoring the bevels for each monitor. With a few key strokes or mouse gestures, I can move between a communication desktop for email or a coding desktop with an active debugger.

Future Upgrades

For the last few years, I’ve been happy with three high resolution monitors. The resolution approaches the limits of human perception. I don’t play any first person shooter (FPS) games, but I suspect it would be awesome.

The latest Dell UltraSharps are roughly comparable to mine. Their $440 U2724D is the same brilliant IPS Black at 2560x1440 resolution that I use. Maybe a little faster. The UltraSharp 32 6K looks awesome with 61544x345 pixels, but it is flat, small, and expensive. A 30 inch monitor at full 4K resolution might be a good replacement for the individual screens, but it is not available.

Curved monitors are interesting, but their radius is far too big. If I believe ChapCPT, the best out there have a one meter curvature radius, and most are out at a two meter radius. With the three-monitor set up that I use, the effective radius is about half a meter. I can move those curved screens out to 1 or 2 meters, but then they are far away.

I’ve been experimenting with projected screens (VR/AR), and the XREAL One Pro is a fun start in a long anticipated direction.
I’ve written about that video experience separately,
and its a good starting point. But their ultrawide mode is projected as a flat screen and is only 1080 vertical. For practical purposes, it is a wonderfully mobile screen with 1920x1080 resolution.

More screens seems unlikely to be an improvement for personal productivity. For focused knowledge work, these monitors display all the information that my human visual system can handle. The 10 foot by 10 foot wall of computer screens on some TV shows might be ok for monitoring large industrial processes, but I can’t see how it would be useful for my daily work.

Modern video GPUs have no problem with multiple monitors. Up to a limit. GPUs seem to work with an 8K (7680 × 4360) virtual space that gets carved up for individual monitors. For me, this means that the practical limit for a commodity video card is three 4K monitors, and one 4K VR.

TLDR

Yeah, the summary is at the bottom. It’s a blog, not a memo.

Think about our human capabilities when you pick your own display system. There are some wonderful human strengths to take advantage of.

Three screens are great, and it comes very close to saturating the human visual field.

I am unrepentant, and I remain a big screen bigot.

The Mini PC For Me

Lee Carver — Thu, 28 Aug 2025 18:39:52 +0000

Can somebody please deliver the software engineering mini-PC of my dreams? It looks like all the parts are out there. I just need it packaged for software development and content creation.

The AMD Strix Halo architecture packages a very attractive bundle of computer power. Lots of resolution - up to 7680x4320 @ 60Hz. Sixteen cores, 32 threads, LPDDR5X memory up to 128GB, high speed WiFi, Bluetooth (BT), USB4, and Ethernet LAN. I’m delighted to see this kind of computing power delivered in a handheld box for prices less than $2K.

But the current wave of hyper-muscular video servers that are masquerading as Strix mini-PCs doesn’t do it for me. All of the mini-PC I’ve seen have a "plethora" of ports. That’s great for a video server on the back-side of a monitor running a build-status display. That’s great for the dedicated kiosk processor with application specific touch-pads or custom controllers.

For a development machine, its a horrible rat's nest of dongles and wasted opportunities. Let’s take that available screen resolution of 7680x4320 @ 60Hz. Typical delivery on that bandwidth is 1 DP port, 1 HDMI port, and 2 USB-C 4 w/ DP-alt mode ports. This sounds perfect for a kiosk video server. A kiosk OEM might even swap out screen components based on what is cheapest today.

My base station has three 27” Dell UltraSharp monitors, each getting a DP (DisplayPort) feed. I’ll need at least two adapters to drive my monitors. That mini-PC ain’t so mini any more.

The Bad Legacy of Video Servers

I’m just guessing here, but the current offerings for mini-PC look like last season’s video server with a hyper-muscular compute package swapped in. From the outside, it feels like the mini-PC builders took their hyper-flexible video server motherboards and swapped out the old pin-pad for an FP11 socket. The result feels like a NASCAR funny car, too much power and not freeway legal.

The crazy mix of video output sources is just the tip of the iceberg. I get that Strix Halo has built-in controllers for every flavor of USB (4, 3.2, 2.0) and multiple ethernet ports, but let’s focus on the ones that are useful for a dedicated development machine.

Take those ethernet connectors. Two of them? Why? Is this device a router? Maybe this is great if you’re daisy chaining a whole hall filled with video servers, but its wasted real estate for a development machine. In that role, a mini-PC is destined for a life as a network terminal device, not a network communication device. Those RJ-45 ethernet connectors are huge. Drop one, and give me two more USB-C ports. Or use the space for one of the three DP ports that I want.

Audio output? For headphones? Really? Great for driving that speaker in a kiosk. In a kiosk, nobody cares about the fidelity anyway. If I’m going to use the mini-PC for audio, it’s probably with my BT headphones. Maybe one on the front, but some mini-PCs have two!

What’s Needed For Software Development

My development machine is pretty static. I have multiple monitors, but the other peripherals I use are very conventional.

Three 27” Dell UltraSharp monitors for video display. It’s a sweet setup, but it isn’t very mobile.
Both the mouse and keyboard are wireless.
An external video camera for conference calls.
An external hard drive provides backup.
I should use a wired Ethernet connection, but WiFi is surprisingly good enough.

That’s it. Everything that isn’t wireless or Ethernet is USB-C.

I can see that folks working with audio or video content would need additional support for media, so an SD slot in front makes sense. Similarly, the Strix Halo is a strong video system, but support for OcuLink to an external GPU seems valuable for content creation.

Getting There

For a mini-PC that targets software developers and content creators, it is essential to focus on a few core principles. Trying to deliver everything for anyone makes it a misfit for me.

Commit to good video, and provide 3 or 4 DP ports for video. I understand the technical appeal of USB-C 4 w/ DP-alt mode, and the marketing push for HDMI to support consumer grade television screens, but none of that is really relevant for a development machine.
Commit to USB-C w/ PD (PowerDelivery). USB-C is the EU standard, it makes sense, it works well. PD helps with everything, too. If I need to connect to a USB-A device, I’ll add a hub. Instead of a barrel connector for DC-in, the USB PD 3.1 EPR standard provides up to 240W.

Detailed Specs

Ranting about problems and spouting platitudes is great fun, but the real work is defining the right mini-PC for software development and content creation work.

I’ve tried to read between the lines of what is out there and what is possible with the available chipsets. It’s not my engineering forte, but here’s my stab at the right device.

Architecture

AMD Strix Halo
WiFi
BT
64GB RAM (or more)
1TB SSD (slot expandable to 4TB)
1x Open SSD (slot expandable to 4TB)
Microsoft Windows 11 Pro
Compatible with Linux

Frontside Ports

Power Button
Status light
USB-C 4.0 w /PD out. out
? Media Port -> use a hub
? Audio -> if marketing insists

Backside Ports

3x - 4x DP ports
1x RJ-45 Ethernet
4x - 6x USB-C 4.0 w /PD out. No DP-alt mode.
1x USB w/PD 3.1 EPR in as power (up to 240W).
? Kensington Lock
? OcuLink

That USB-C w/PD on the front isn’t just another port. I know I will use it to charge my phone.

How About It?

Let's call this the “Strix Halo - Content Generators Edition”. Let it deliver that massive compute power to all the software developers that can really enjoy it and exploit it. But targeting any possible configuration of video and peripherals is such a wasted opportunity.

A system like this probably calls for a new motherboard, with a whole different set of headers for the different IO ports. That engineering is outside of my expertise.

I get this is a niche machine. A market of maybe a few million software and content developers is nothing compared to the billions of video servers out there. Surely there to be enough of us to cover the upfront engineering costs.

Bring it on. Please.

The New Path

Lee Carver — Thu, 17 Jul 2025 16:08:09 +0000

I submit the attached as a modern update on Randall Munroe's classic https://xkcd.com/303.

Ok XREAL, Blow Me Away

Lee Carver — Mon, 14 Jul 2025 21:06:01 +0000

I'm a big screen bigot.

I have been ever since the late '80s when I got my first 21-in screen. In that era of 14” 24 line 80 column monochrome monitors, a 21" 1280x1024 grayscale display was breathtaking.

My desire for large screens has only increased as our computer’s capabilities have increased. So I was delighted to hear about the XREAL One Pro’s huge display and field of view. Among the other cool reviews, Mr. Spadafora describes a slick mobile computing solution and Mr. Miller describes a smooth working environment with these devices.

The XREAL One Pro is wonderful, but it's not everything I was hoping for. It’s a friend zone device, not love at first sight. If XREAL could go full 4K on the display, now that would blow me away.

Getting Started

It took a bit to get my XREAL One Pro configured properly. It seemed to fit well, but the images had some blurriness and color edges. This initial fuzziness needed to be corrected with a diopter setting. You may need to adjust the nose piece. I went through all three choices, returning to the original medium nose pieces after several several experiments. It helped a lot to tilt the earpieces for a lower image placement.

There are several display modes and it took me a while to find the widescreen mode that is such a joy. It's a beautifully wide image with 3840x1080 resolution. That’s as wide as a 4K TV, but less than half the vertical resolution. Regardless, it would truly be an imposing device as a physical screen.

The XREAL One Pro shows only a portion of that display, but the head tracking system provides a view of the entire screen. That’s great for the image, but less wonderful for typing. I’m not the touch typist I could be, so I look at the keyboard .. a lot. With regular practice, I can probably learn to look down without moving my head, but I’m not there yet. These things would be easy enough to live with.

Comparisons

My main challenge with the XREAL One Pro’s widescreen mode is the limited number of vertical pixels. It’s almost as wide as my current display setup (just under 90%). But it is woefully short on vertical height, with not even half of my current resolution (42%). Combined, the available screen space is only 38% of my normal screen space.

As I said, I'm a big screen bigot. My current setup is three 27” Dell UltraSharp monitors set vertically, side by side. Each monitor is approximately a 3K display, with 1440x2560 resolution. Configured vertically side-by-side, that’s an effective display of (1440*3) x 2560 side. The total is 4320x2560, or just over 11 million pixels (11,059,200) . Configured at arms length (about 2 feet), this setup pretty effectively fills my entire field of vision. It’s an extremely effective way to show multiple browser windows without overlaps.

A snapshot from the Windows Display configuration gives a visual comparison of the resolution. The XREAL One Pro’s window (2) is indicated above the windows provided by the three Ultrasharp monitors (4), (3), and (1). The XREAL’s window is almost as wide, but not even half as tall.

The XREAL’s 3840x1080 resolution just can’t compete with the multiscreen resolution of 4320x2560 pixels. It is a huge improvement coming from commodity laptop screens, but it can’t replace my daily workstation’s display.

Conclusion

As much as I was hoping the XREAL One Pro might replace the multiple screens of my main development system, the currently available screen sizes just aren’t comparable.

I think the XREAL One Pro is a great device for mobile arrangements. I’m looking forward to following in the footsteps of Mr. Spadafora and putting together a fully mobile computing system.

And c’mon XREAL - make widescreen mode offer full 4K resolution. Maybe then those UltraSarp monitors can head off to retirement .. like my old 21” CRT.