If you have spent any significant amount of time navigating the modern Linux ecosystem, the chances are high that you have already interacted with software built by Mirko Brombin. Over the years, Brombin has left an indelible mark on open-source software through projects that consistently push the boundaries of user experience and compatibility. He is the creator of Bottles, the popular application that successfully abstracts away much of the historical friction involved in running Windows software through Wine. He also founded Vanilla OS, an ambitious immutable distribution designed to redefine reliability and maintenance on the desktop.
Today, Brombin is channeling his technical vision into new territories, spearheading the development of Singularity OS—an operating system featuring its own custom desktop environment and a distinct paradigm for system immutability.
When we last spoke with Brombin back in 2022, his primary focus was on establishing long-term sustainability for his projects while working toward full-time open-source development. A significant amount of ground has been covered since that conversation. Brombin now works full-time at Fabricators, is actively engineering compatibility solutions to run Microsoft Office through Bottles, and holds strong, unfiltered perspectives on the rapidly evolving role of artificial intelligence in software development, alongside the recent industry trend of applications cloning proprietary software interfaces.
Reflecting on his prolific output, which spans full-time employment at Fabricators, the ongoing maintenance of Bottles, the development of Sinty OS, and a vast repository of auxiliary libraries and tools, Brombin admits that his workflow defies traditional planning. Anyone familiar with his trajectory over the years knows that he is rarely content to remain stationary.
"I’ve never really had a proper strategy for deciding what to dedicate my time to," Brombin explains. "Most of my projects are born from a problem I want to solve, an idea I want to experiment with, or simply the curiosity to find out whether something is possible."
Naturally, balancing a demanding full-time professional schedule at Fabricators with the sustained maintenance of multiple high-profile open-source initiatives has forced him to adopt rigorous prioritization. In an ecosystem where demands from users and contributors are relentless, recognizing that not every experiment needs to blossom into a complete, standalone product has become a vital survival mechanism.
The Complex Reality of AI in Software Engineering
The conversation naturally turns toward artificial intelligence, a subject Brombin has written about extensively, particularly regarding the use of AI agents to handle the more mechanical aspects of software engineering. For Brombin, integrating AI into a daily workflow is a nuanced topic that requires careful navigation, especially within the open-source community where public perception is delicate and free software represents both a personal passion and a livelihood.
It is remarkably easy for developers to be misunderstood in the current landscape, falling into binary camps: those who view artificial intelligence as a silver bullet capable of solving every technical hurdle, and those who reject the technology entirely. Brombin positions himself outside both extremes, shaped by a historically complicated relationship with large language models. Initially approaching LLMs with deep skepticism, he found that the more he examined their inner workings, the harder it became to place blind trust in them.
"The problem isn’t the quality of the code they can produce, but understanding why they produced that particular code," Brombin notes. "When I design software, I start from the architecture, I decide how the components should interact, what responsibilities they should have, how to handle errors, which compromises to accept and, logically, which ones to avoid."
This architectural blueprint is documented meticulously so that every decision remains coherent and understandable years down the line—a deliberate creative process that Brombin refuses to delegate. To illustrate his methodology, he points to his extensive use of Go, a language in which a large portion of his personal and professional infrastructure is written. Over years of development, he has established a distinct set of libraries, patterns, and coding conventions. When he employs AI assistance, he does not ask the model to invent an architecture from scratch. Instead, he supplies his own structural guidelines, documentation, and hard constraints. He remains the sole architect of how a project is conceived, how it evolves, and when it reaches its natural conclusion.
Despite utilizing agents for routine tasks, Brombin still writes a substantial amount of code manually, either to handle particularly delicate components or simply because doing it himself proves more efficient. Crucially, every single line of code generated by AI undergoes thorough manual review. If a piece of generated code fails or introduces a flaw, he takes full responsibility for accepting it.
Yet, a fundamental philosophical objection remains regarding how language models operate. While an LLM can generate a correct answer and even trace the apparent logical steps that led to it, Brombin finds this process fundamentally opaque from a rigorous engineering perspective.
"An LLM can produce reasoning, but it doesn’t necessarily possess an explicit, persistent, and causally verifiable representation of the knowledge it uses to express that reasoning. And this bothers me quite a lot," he explains.
If an autonomous agent selects a specific data structure, Brombin expects to know whether that choice was made because official documentation dictated it as the optimal solution, or simply because statistical probability deemed it plausible within the given context. Recognizing that these two concepts are fundamentally distinct has driven him to research and experiment with alternative paradigms. This ongoing research project, called Amus, explores novel ways of representing knowledge and constructing computational answers, striving to make the underlying relationships of any logical conclusion fully explicit and verifiable. Although still in its early research phases with details largely under wraps, initial results have been encouraging.
Ultimately, while AI agents have enabled a single developer to shoulder a volume of work that would have been unimaginable just a few years ago, the very nature of the technology has prompted Brombin to rigorously question its underlying foundations.
The Evolution of Vanilla OS and Community Stewardship
When the conversation shifts to Vanilla OS, the landscape has shifted noticeably since 2022. While the original vision centered on building a sustainable project that could support full-time development, the project’s official web presence now designates it as community-run.
Brombin clarifies that the core operational reality of Vanilla OS has not fundamentally deviated from its original trajectory. The operating system continues to see active maintenance and critical updates, prioritizing system security and stability. A notable milestone was the recent release of Vanilla OS 3 Reunion, which required an immense engineering effort to introduce ARM architecture support alongside the creation of the Vanilla OS SDK. This development kit allowed the team to rewrite foundational system components, ensuring everything operates seamlessly on a single unified base.
Today, the project no longer relies solely on Brombin’s individual efforts. A dedicated team of contributors handles various aspects of development, while Fabricators generously maintains the underlying server infrastructure. Coupled with an active community of users reporting bugs and submitting fixes, the project has matured.
Brombin’s personal day-to-day role has evolved accordingly. While he still contributes code—such as engineering Vanilla OS Continuity, the backup system integrated into Vanilla OS 3 Reunion—his responsibilities have expanded into strategic leadership. He navigates the political dimensions of keeping the project financially viable while steering its long-term architectural vision. In essence, while the community drives everyday execution, he remains at the helm.
Redefining Compatibility: Bottles, Raven, and Microsoft Office
Reflecting on the inception of Bottles in 2017, the open-source landscape already featured established tools like Wine, PlayOnLinux, and Lutris. When asked what specific gap motivated him to build yet another compatibility layer, Brombin offers a characteristically candid response rooted in personal dissatisfaction.
While Wine was already an extraordinary piece of technology, and its contemporary frontends provided valuable assistance, none of them matched his exact definition of software simplicity. His goal was never merely to construct another application launcher or installation script. Instead, he envisioned an environment where Windows applications could be managed effortlessly, eliminating the need to constantly drop into the command line or manually manage DLL placements.
Brombin has long observed a peculiar cultural quirk within the Linux community: an uncritical acceptance that technically complex tools must inherently be difficult for end-users to operate. He views this as an unnecessary stereotype. The internal complexity of a software stack should never become an active burden for the user, even when the underlying architecture of a tool like Bottles resembles a tangled web of dependencies. This exact philosophy underpins his latest endeavor, Raven. Designed as a tool where Windows applications are recognized natively, Raven aims to let users install and run Windows software with their original installers without requiring a full Windows virtual machine, though compatibility remains actively under development.
Addressing the perennial debate within the Free and Open Source Software community—where critics often argue that developer effort is better directed toward improving native alternatives like LibreOffice or OnlyOffice—Brombin rejects the premise that these initiatives must be mutually exclusive.
While LibreOffice and OnlyOffice remain fantastic software suites that he readily recommends to anyone transitioning from Windows, Brombin points to the undeniable realities of the professional world. In his own professional environment, he enjoys the freedom to use customized setups like Singularity OS and its native productivity tools. However, the vast majority of his clients, partners, and corporate entities rely heavily on Microsoft Office due to external certification requirements, corporate compliance, and established enterprise workflows.
"I’m the first to say that users should have a choice, and I create those choices myself… But that’s the ideal world," Brombin explains. "The real world is that sometimes we simply can’t afford to make the choices we’d like to make."
This pragmatic realization drives his ongoing work to get Microsoft Office running reliably through Bottles via projects like Soda. When asked whether these technical fixes will remain isolated to Bottles or eventually find their way upstream into Wine for the broader ecosystem, Brombin confirms his ultimate intention is to contribute upstream as much as possible, provided the core Wine maintainers approve of the patches. The immediate priority, however, is reaching a stable state where Microsoft Office 365 functions reliably before initiating upstream collaboration.
Concerns Over Proprietary Clones and Interface Replication
Beyond compatibility layers, the broader Linux ecosystem has recently witnessed a wave of applications attempting to clone popular proprietary suites—such as Adobe and Microsoft tools—almost down to the individual pixel. When asked whether copying familiar user interfaces represents a viable strategy for winning over mainstream users or if Linux requires distinct design ideas, Brombin expresses deep reservations.
This particular trend is one he finds genuinely troubling. He objects strongly to what he views as a violation of product identity. While discussions surrounding clean-room design are frequently invoked to justify these projects, Brombin questions the validity of such defenses when developers deploy swarms of AI agents instructed to keep proprietary applications open to replicate them down to the millimeter.
"It’s not illegal… The practice itself isn’t. But stealing, because that’s what this is, the visual identity of that project is, it’s called copyright infringement, and in some cases even unfair competition," Brombin remarks.
He questions the ultimate utility of creating pixel-perfect replicas, arguing that the open-source community should focus on functional parity and innovative design approaches rather than visual imitation. He warns that validating such practices sets a dangerous precedent that could heavily distort the future trajectory of open-source development.
Sinty OS and the Pursuit of True Immutability
In parallel with his work on Vanilla OS and Bottles, Brombin is deeply immersed in developing Singularity OS, known colloquially as Sinty OS. When asked why he chose to build an entirely new desktop environment and kernel platform from scratch rather than adopting existing components from established desktop projects like GNOME or KDE, he clarifies the distinct philosophies separating his operating systems.
Sinty OS represents everything that Vanilla OS cannot be due to its foundational design principles. While Vanilla OS adheres strictly to upstream GNOME principles, utilizing pure GNOME and Libadwaita for a cohesive, standard experience, Sinty OS is engineered to provide a unique, highly tailored desktop environment.
Technically, Sinty OS tackles an entirely different set of engineering challenges. It relies on Atom Loops, an immutable technology developed by Brombin that differs fundamentally from ABRoot and existing solutions. Atom Loops manages system immutability from the very first second of the boot sequence. The bootloader and the initial RAM filesystem are governed by this component, maintaining a strict chain of trust and cryptographic update validation.
Instead of traditional partition-based system roots, Sinty OS leverages image files—specifically utilizing EROFS for the root filesystem and UKI for the kernel cache—which are dynamically mounted by Atom Loops at boot. This architecture ensures that the entirety of the underlying disk space, formatted as F2FS, remains dedicated to the user. Furthermore, unlike Vanilla OS, Sinty OS bypasses LUKS entirely, encrypting user files using distinct, unique keys. Combined with an ultra-minimal init system compatible with systemd units, the two operating systems represent radically different architectural approaches to achieving similar overarching goals.
As development continues under the Sinty banner—referring collectively to the family of software encompassing Singularity Desktop and Singularity OS—Brombin indicates that numerous applications and interconnected platforms will soon emerge.
Concluding with a message to the open-source community, Brombin encourages developers and enthusiasts alike to lean into experimentation, particularly in an era where modern technology provides the tools necessary to think expansively. Rather than viewing boundaries as absolute limits, the true excitement lies in discovering how to push past them.
