If you have spent any significant amount of time within the Linux ecosystem over the past several years, the chances are high that you have interacted with software built or conceptualized by Mirko Brombin. As the creator of Bottles—the utility that substantially streamlines the process of running Windows applications via Wine—and the founder of Vanilla OS, Brombin has long been a prominent figure in the open source community. Today, his focus has expanded further into ambitious new territory, including the development of Singularity OS, an operating system featuring its own custom desktop environment and a distinctive approach to system immutability.
When It’s FOSS last spoke with Brombin in 2022, the landscape of desktop Linux was markedly different, and his primary objective was establishing enough project sustainability to transition to working on Vanilla OS full-time. A great deal has transpired since that conversation. Brombin now works full-time at fabricators, continues his efforts to make Microsoft Office fully operational on Linux through Bottles, and harbors sharp perspectives concerning the broader implications of artificial intelligence and the recent emergence of open source applications cloning proprietary Adobe and Microsoft interfaces.
Balancing Full-Time Engineering, Project Maintenance, and Evolving Priorities
Juggling full-time employment at fabricators alongside the ongoing maintenance of Bottles, Singularity OS, and a vast ecosystem of smaller libraries and tools naturally raises questions regarding resource allocation. According to Brombin, anyone familiar with his trajectory over the years understands that sitting still is rarely part of the equation.
Rather than relying on a rigid, corporate strategy for project prioritization, most of his initiatives emerge organically. They are typically born from a concrete problem he wants to solve, an experimental concept he wishes to test, or simple technical curiosity regarding whether a specific feat is achievable within the constraints of modern software engineering. However, the reality of maintaining multiple high-visibility open source projects while holding a demanding full-time position has necessitated a pragmatic approach to time management. Not every side project can command equal attention, nor is every experimental tool destined to mature into a complete, standalone product.
Navigating Artificial Intelligence: Practical Tool or Philosophical Dilemma?
The integration of artificial intelligence agents into software development has reshaped the workflow of many developers, and Brombin is no exception. However, his relationship with large language models and AI tooling is nuanced, deeply considered, and distinct from both uncritical techno-optimism and blanket rejection.
In open source communities, discussing artificial intelligence can be a delicate undertaking, particularly for developers with a public profile who rely on free software for both livelihood and creative expression. Brombin notes that it is remarkably easy to be misunderstood by both ends of the spectrum—those who view AI as a panacea for every programming bottleneck and those who reject the technology outright. Initially harboring deep skepticism, his trust in LLMs did not come easily as he sought to understand their underlying mechanics.
The core hesitation does not stem from the raw quality of the code that modern agents can generate, but rather from the opacity of why that specific code was produced. For Brombin, software design begins with architecture: deliberately deciding how components should interact, defining specific responsibilities, establishing error-handling protocols, and explicitly choosing which compromises to accept or avoid. This architectural blueprint is meticulously documented to ensure every decision remains comprehensible years down the line—a deliberate creative process he has no intention of delegating.
In practical development environments, much of the infrastructure Brombin builds is written in Go. Over years of engineering, he has cultivated a precise personal toolkit of libraries, design patterns, and coding conventions. When utilizing AI agents, he does not ask the model to invent an architecture from scratch; instead, he provides his own architectural frameworks, comprehensive documentation, existing conventions, and strict constraints. He remains the sole architect guiding a project from its inception through its evolution.
Furthermore, a significant volume of code is still written entirely by hand, either to tackle particularly delicate low-level components or simply because manual implementation proves faster in certain scenarios. Every line of code generated by an AI assistant is subjected to rigorous manual review.
Despite utilizing these agents to handle mechanical workloads—thereby enabling a single developer to accomplish an amount of work that would have been unimaginable a few years ago—the underlying epistemology of LLMs remains a point of philosophical friction. An LLM can formulate a syntactically correct answer and articulate seemingly logical steps, but that reasoning lacks an explicit, persistent, and causally verifiable representation of knowledge. If an agent selects a specific data structure, Brombin wants to verify whether that choice was made because explicit documentation mandated it as the correct solution, or simply because statistical probability deemed it plausible within the given context.
This distinction has driven him to research and experiment with alternative paradigms. Through an ongoing research initiative titled Amus, he is exploring alternative methodologies for representing knowledge and constructing programmatic answers, aiming to make the logical relationships leading to a conclusion transparent and verifiable. While still in early research phases, initial results have proven encouraging, with plans to share broader technical details publicly in the future.
Vanilla OS: Evolution into a Community-Driven Enterprise
When discussions turned to Vanilla OS, Brombin addressed the transition of the project’s status on his official channels, where it is now formally designated as community-run. In 2022, the stated ambition was achieving sufficient financial and structural sustainability to work on the operating system full-time.
The core mission of Vanilla OS has not wavered, and the project continues to receive consistent security and stability updates. A major milestone arrived with the release of Vanilla OS 3 Reunion, which required an immense engineering effort to introduce ARM architecture support alongside the development of the Vanilla OS Software Development Kit. This internal SDK enabled the rewrite of several fundamental operating system components, ensuring that disparate parts share a unified foundation.
Today, the project no longer rests entirely on a single pair of hands. A dedicated team of contributors handles daily operations, while fabricators maintains the core server infrastructure. Community contributions, ranging from bug reports to actionable code patches, remain vital to its ongoing health. Brombin’s personal role has similarly shifted toward strategic leadership—securing financial sustainability and steering high-level architectural decisions, while occasionally dropping down into code to build tools like Vanilla OS Continuity, the backup system integrated into the Reunion release.
Challenging Conventions in Application Compatibility: Bottles and Raven
Reflecting on the inception of Bottles in 2017—at a time when Wine, PlayOnLinux, and Lutris were already well-established fixtures of the Linux gaming and compatibility landscape—Brombin recalls that his entry into the field stemmed simply from personal dissatisfaction with existing options. While acknowledging the foundational brilliance of Wine and praising contemporaries like Mathieu and the Lutris team, none of the available tools matched his precise definition of software simplicity.
His goal was never to craft merely another game launcher or generic installation wrapper, but to engineer an environment where users could manage Windows applications without constantly resorting to the command line or manually placing DLL files across hidden directories. Brombin has frequently observed an underlying cultural acceptance within the Linux community that technically complex backends must inherently necessitate complicated user interfaces. He views this as an unnecessary barrier: the internal complexity of an application should remain insulated from the end user, even when managing a deeply intricate compatibility layer underneath.
This philosophy serves as the driving force behind the newly announced project, Raven. Designed as a utility where users can install and run native Windows applications on Linux directly through their original installers—completely bypassing the need for a traditional Windows virtual machine—Raven represents the next iteration of Brombin’s work in application compatibility, with core compatibility layers actively under development.
The Practical Case for Microsoft Office on Linux
Within the Free and Open Source Software community, a persistent philosophical debate questions whether engineering effort is better channeled into improving existing native open source suites like LibreOffice and ONLYOFFICE, rather than attempting to make proprietary software like Microsoft Office run smoothly on Linux platforms—especially given Microsoft’s capacity to break compatibility with routine updates.
Brombin rejects the premise that these objectives must be mutually exclusive. He describes LibreOffice and ONLYOFFICE as fantastic software packages that remain his primary recommendations for everyday users transitioning from Windows to Linux. However, professional realities demand pragmatism. In daily professional environments, many clients, corporate partners, and external stakeholders rely exclusively on Microsoft Office for formal compliance, certifications, and enterprise workflows.
While an idealist framework suggests complete independence from proprietary ecosystems, the real-world operational environment often denies professionals the absolute freedom to choose alternative file formats. Bridging that gap is a practical necessity rather than an ideological surrender.
Regarding technical execution, the current work on integrating Microsoft Office via the Soda project within Bottles is intended to extend beyond a localized utility. While initial efforts focus on achieving reliable stability for Microsoft Office 365, the ultimate objective is upstreaming successful patches directly into Wine, ensuring that the entire Linux compatibility ecosystem benefits from the discovered solutions rather than keeping the fixes siloed within a single application.
Critiquing the Wave of Proprietary Interface Cloning
While technological interoperability remains a core passion, Brombin expresses significant concern regarding a recent trend within the broader open source and alternative software ecosystem: applications that clone popular proprietary software suites, such as Adobe and Microsoft tools, almost one-to-one down to the pixel.
Brombin is openly critical of this movement, questioning the ethical boundaries of replicating the visual identity and user interface of proprietary products. While proponents often invoke clean-room design principles, he challenges the validity of such claims when development workflows rely heavily on automated AI agents instructed to keep Microsoft Word or Adobe Photoshop open to replicate them with millimeter precision.
Beyond strict legality, he characterizes the wholesale duplication of another entity’s visual identity as a form of copyright infringement and unfair competition. More fundamentally, he questions the long-term utility of spending vast community resources to recreate an exact pixel-for-pixel replica of Microsoft Office, arguing that open source innovation is better served by developing distinct ideas, novel interfaces, and original approaches to productivity.
Sinty OS and Atom Loops: A New Approach to Immutability
Beyond Bottles and Vanilla OS, Brombin’s development efforts are heavily concentrated on Sinty OS, a project that explores architectural concepts distinct from Vanilla OS due to differing foundational principles.
While Vanilla OS adheres strictly to pure GNOME principles, utilizing libadwaita and maintaining complete alignment with upstream desktop design guidelines, Sinty OS provides a tailored, distinct desktop environment designed to offer a specialized user experience.
On the architectural level, Sinty OS represents a major technical departure, resting on Atom Loops—a custom immutable system framework designed by Brombin as an alternative to ABRoot and existing immutability models. Atom Loops governs system immutability from the very first second of the boot sequence, managing the bootloader and initramfs through a strict chain of trust and update validation.
Rather than utilizing traditional system root partitions, Sinty OS relies on image files, employing EROFS for the root filesystem and UKI for the kernel cache, which are mounted dynamically by Atom Loops at boot time. This architecture ensures that all available disk space, formatted utilizing F2FS, remains entirely allocated to the user. Furthermore, user file encryption diverges from standard implementations like LUKS, instead utilizing unique per-user keys. The underlying initialization system is similarly unconventional, replacing systemd with an ultra-minimal alternative while maintaining full compatibility with standard systemd units.
Looking Forward
As development continues across Singularity Desktop, Atom Loops, Raven, and the broader Singularity ecosystem—increasingly unified under the concise identifier Sinty—Brombin encourages developers and enthusiasts alike to lean into experimentation. In an era equipped with advanced technological frameworks capable of supporting complex engineering feats, the prevailing open source mindset should focus less on accepting inherent limitations and more on systematically dismantling them.
