I think they explain a compelling problem about typical commerical software vs FOSS, then they dive into their GPU accelerated VM solution. I don't see how it helps solve the original problem.

Is is that FOSS needs a standard sandbox and they think some kind of peer to peer app store that disturbes images for VMs is the way to do it?

We work on GPU accelerated VMs, so that in future we can also bring NixOS + VPNs to desktops/end users to machines that don't run NixOS. We will use it as an application runtime where can control the whole stack. Just now we are mostly focused on managing distributed NixOS machines. The VPN helps to provide services on any kind computer, even if not running in a datacenter. You can read the description here for context: https://docs.clan.lol/

Maybe I'm in the same boat as people who didn't get docker before it was popular, but this seems really convoluted to me... is there really a market for this? Why do other existing things not solve this problem?

There is huge demand right now to create sandboxes for agents. VMs are one way, and Clan one solution for VM management.

Maybe they are not the right solution, but they are working on the right problem.

Of course, they don't say the focus on agents, but if the solution works with them, it doesn't matter that it was built for gamers.

P2P app distribution is cool in theory but the security model gets complex fast. Without centralized review, you're basically trusting individual developers to not ship malicious code.

I resonate with what the author said about losing track of the Mental Model. I think that's the key to enjoying the process or not. I.e. the building up or utilising of that mental model (my own understanding) is they key to finding software development joyful.

Specifically:

"Easy but boring project" case: For projects where I am already familiar with a strong and sensible architecture then I find AI enjoyable to work with as a simple speed boost. I know exactly what I'm asking AI to do at every stage and can judge it's results well. It's not that interesting to me to code these components myself because I've done it before several times. My mental model of the problem space and a good solution is complete. I get some satisfaction from using my mental model.

"Challenging but interesting project" case: For projects where I don't yet understand the best architecture then I will inevitably ask AI to connect Component A to Component B without yet understanding that there should be a Component C. Because I don't have the understanding of the problem space. The thing is before AI I may have made this mistake myself, I just would have had the satisfaction of learning at the same time.

Given the time with these type of projects I basically write them twice: First pass making it work but as a huge mess, but building a mental model of the real problem space along the way. Second pass refactoring and getting it right, creating now a mental model of a good solution. Only after two passes would it be a project I would feel is done correctly and be happy (joyful) to publish it.

I have found AI enables you to get the first pass working much quicker, but without the learning along the way of the mental model to inform how to make the second pass properly. So If I want the challenging project to be joyful I still need to invest the time to learn from the first pass.

And that specific learning task I enjoy more if I do it iteratively as the AI and I build together, it's less enjoyable if I sit down afterwards and only inspect the code.

SO if I want a challenging project to be joyful I have to continue investing the time in the first phase to do the learning. AI just gives the opportuntity to produce a messy working prototype without learning anything, which may or may not make sense for the business side of things.

We expect comitted founders to make the best of their constraints.

This founder is doing that by putting a positive spin on their constraints in their social media posts.

Fallibility is important and I hope that founder is honest with their team, but at the same time keeping a positive public narrative about your company is also important. Not everyone has to perform their growing pains in public.

Additionally, founders/CxOs talking about or admitting to problems in public is rarely ever a good thing as it reduces confidence in the company - a prime example being the burning platforms memo[1].

[1] https://www.theguardian.com/technology/blog/2011/feb/09/noki...