Dario Casalinuovo isn’t a name you’ll easily find in mainstream search results, but his work has left a real mark on the history of Haiku and the BeOS ecosystem. From the OpenBeOS Media Kit to VitruvianOS, an ambitious project bringing BeOS DNA on top of the Linux kernel, without X Server, without Wayland, without easy compromises, Dario has always pursued a precise idea: putting the human being at the center of the operating system, not market demands or the latest tech trends. In this interview, he walks us through his journey, his choices (including the difficult ones), and the technical and philosophical vision driving VitruvianOS today.
Q: Looking back at your early days as a programmer, what drew you toward operating systems development, and what fascinated you about BeOS compared to the giants of that era like Windows and Linux?
Like many of my generation, my entry into computer science came through video games, the PlayStation era. With just a basic understanding of computers from school, I eventually got my own machine, largely to explore the web and play games.
I remember buying computer magazines alongside comics, they were impossible to overlook. That’s where I first heard about BeOS, around 2001. Around the same time, I found an introductory book about C in a bookstore and invested my limited funds into it. Initially, creating video games was the appeal, but I soon realized something more profound: if I learned programming, I could create things. That was the key realization, that persistence would eventually lead to understanding how everything worked.
Like most others, I started with Windows, but it didn’t take long, perhaps a year, before I began exploring live CDs like Knoppix. Eventually, I found a Linux distribution at the local newsstand: Mandrake, running Linux 2.4. From there, I managed to get my hands on BeOS PE and learned to install it. I ran BeOS and Linux in dual boot for quite a while until BeOS simply wasn’t capable of running modern websites and programs anymore, at that point, it no longer made sense to maintain it. Linux has been my main operating system from then until now. That constant shifting between two worlds taught me how systems could be approached differently, how the same goal could be achieved through fundamentally different philosophies. That understanding became foundational. I think that dual perspective was important for my formation and growth.
Q: During your work on critical systems like the Media Kit and service APIs, what was the most complex technical challenge in modernizing an architecture originally designed in the 1990s?
The Media Kit is genuinely difficult to work with because, on paper, it was designed to support a vast array of use cases, but in reality, that never materialized the way it was envisioned. Beyond the daily maintenance work, the real challenge was that when I started, it hadn’t been proven to work reliably in production.
It took enormous effort and many reboots just to gather the needed changes to at least prevent it from interfering with other services. This was overlooked at the time, but it was quite an advancement for the status of the system. In the early stages of OpenBeOS, this was a big machine that needed a lot of care to run correctly with all its running parts. It’s hard to pinpoint a single problematic feature, this was a comprehensive challenge that consumed considerable time. Both the developer who worked on it in the early stages and I found it challenging. It was long, grinding work.
Q: I know there were significant changes in your open-source contributions in the past. Can you tell us how that shaped your priorities and redefined your path?
I expected this question. Let me start by saying we’re talking ancient history now. While for some people time may have stopped there, I’m someone who always looks forward. It’s really the distant past for me.
In retrospect, I won’t deny that things could have been handled differently, and I hope others recognize that as well. Ultimately, leaving was the right decision. Moving on freed me to redefine my objectives. Fortunately, I’d already started a side project that became my focus, something where I could invest time in work I found genuinely useful. It has never become a daily OS for me anyway.
My priorities did shift, and in my view, for the better. People occasionally ask if I’d return to finish what I left behind, but honestly, that chapter is closed for me. We’ve all been through a lot in recent years, and sometimes things simply come to an end. Not everything comes back around. Hopefully, this puts a final ending word on the thing.
Q: With VitruvianOS (V\OS), you’re attempting to resolve an eternal dilemma: the user philosophy of BeOS combined with the robustness of the Linux kernel. What was the exact moment you realized that creating a new system was better than refining an existing one?
The question is: what do you do when you have the arguably most advanced kernel in the world, one that runs on virtually everything, paired with a GUI that works well, enables advanced users to express themselves, and still provides an easy, Unix-like experience comparable to famous desktop operating systems?
It felt like a natural consequence. I’ve had similar ideas for over 15 years. There was always discussion about X server alternatives, and I thought they’d eventually be solved. I use Linux and X regularly with a lightweight display manager, but you never quite capture that sense of connection to the user interface that you have with BeOS R5.
I continued developing the project quietly for years, partly because I had to acquire the necessary skills myself, and partly because I needed to handle real-world responsibilities such as a job and family. Ten years ago, I wouldn’t have imagined Vitruvian would still be relevant nowadays. But eventually, I decided it was time to commit fully and announce the project seriously.
People know I’m working on it since about 2019. I’ve completely rewritten it since then and developed the sophisticated infrastructure that allows the Tracker to run on systems beyond BeOS or compatible clones. That alone is sensational news, no one has ever run the Tracker outside BeOS or Haiku before. It’s something that was considered impossible. When I rewrote it, I introduced Nexus, and I regret not starting with that implementation in the first place. While I appreciate the theoretical purity (which never materializes) of some projects alternative to Vitruvian, I don’t see other projects offering development prospects aligned with my expectations.
Some might see Vitruvian as nostalgic retrocomputing, but that’s not what this is. Yes, we’re based on some BeOS-like legacy, but the reality is more nuanced. We’re here to stay. Vitruvian is not an operating system like others.
What we’ve built is a bridge. The Nexus kernel subsystem is the heart of this, it brings BeOS-style node monitoring, device tracking, and messaging to Linux. This allows applications written for BeOS or compatible systems to run natively on a standard Linux kernel without requiring binary compatibility or emulation layers like WINE. That infrastructure is what makes the whole thing possible.
There are lots of myths around how a Linux-based OSBOS system should be implemented. Vitruvian will show that many of the assumptions about how such a system should work are actually wrong. We’re challenging those assumptions with every decision we make. Historically some kind of propaganda has shifted decisions on directions that should be put back to discussion. By starting with a plain board and the best ingredients possible, we will show how different choices lead to fundamentally different outcomes.
Q: Vitruvian’s claim is “The Operating System with the human at the center.” In a world dominated by increasingly heavy, cloud-service-oriented operating systems, how does this vision of “human centrality” translate technically into V\OS code?
We live in a world where things are designed to be sold, and it’s absurd how much of what we use daily isn’t actually designed with the human user in mind. This applies to operating systems as much as anything else, it always has.
But what if we tried something genuinely different? What if we sat down and thought: what would I actually want to do with my laptop that I currently can’t? If you sit with that question, interesting things emerge. The difference now is that a wide variety of alternatives are available. So why not explore them?
The human-centered approach means rethinking defaults, simplifying complexity, and ensuring the system serves the user, not the other way around.
In Vitruvian, we set sensible defaults and let people who want to dig deeper do so, but the average user gets a system that just works. We don’t prevent expert users from going even deeper into the system so that it can fit their specific needs. That’s the difference between respecting the user and respecting every possible hypothetical use case.
Technically, this translates to decisions like removing unnecessary layers of abstraction, choosing direct communication between components over middleware, and building features that respond immediately to user input. We avoid bloat and complexity in the codebase itself. The system is transparent, you can see what’s happening. There’s no invisible machinery working against your intentions.
Beyond software, Vitruvian is planning to support integration with hardware that will limit the need of cloud services. You should own your data and your computing experience, not rent it from a corporation.
The name could remind you of Vitruvius among other things, the Roman architect who wrote De Architectura, a work that profoundly influenced how we think about building things. The principles in that book centered on beauty, utility, and structural integrity working together. That’s exactly what we’re trying to do with Vitruvian: architecture that has beauty and the actual use of infrastructure in mind.
Q: Developing an operating system from scratch presents enormous challenges, from kernel to UX. What are the biggest technical hurdles you’re facing with VitruvianOS today, and where is development focused right now?
Our user interface is currently nearly identical to what you find in BeOS-compatible systems. We’ve stripped out certain components, but the majority of what people know is still there. Some services will be replaced by modern equivalents to better serve contemporary needs.
Take the Mail Kit as an example. On paper, it’s a reasonable idea, but after more than 20 years, hasn’t it proven insufficient for everyday use? We’d rather have a simple, fast, secure mail client that properly supports IMAP and modern email protocols by default. The Mail Kit should be an external package for nostalgics, but we’d rather have a working email client out of the box. If someone wants to add an option to store emails as attributes, great, we’d welcome it. But that’s an enhancement, not the default experience.
We’ve rethought components from first principles. For example, we completely reworked and taken the Linux keymap system to build our own input system. We handle cases where developers hardcode character codes, and in exchange, we get an input system compatible with virtually everything, mice, gestures, tablets, everything we need.
Currently, the input system in Vitruvian is still basic. I’m sequencing the activation of system components so the most fundamental layers stabilize before more sophisticated features launch. V\OS 0.3.0 is a pilot release. The work of solving these critical technical challenges has been substantial, but we’ve stayed focused.
Vitruvian isn’t quite usable yet, but if you ever wanted a Linux-based OpenBeOS so to speak, we’re the closest thing that’s ever existed. Now that the most fundamental bricks are in place, we’re going to move fast. The foundation is solid, and we can finally start building on top of it.
It’s worth noting that Vitruvian doesn’t use X Server or Wayland, and it doesn’t really depend on classic Linux desktop components. We do use essential stuff like udev and libseat for VT switching, but we’ve built our own graphics layer and display system from the ground up. That’s part of what makes this possible.
Porting a BeOS-compatible runtime on top of Linux is genuinely difficult. Binary compatibility is impossible unless you want something like WINE. Vitruvian is more akin to Android than an emulation layer. Our nexus serves the same role that the binder does on Android. Vitruvian native apps are truly native Linux apps.
We’re also planning a modern media framework capable of low-latency audio as well as 8K video. It will be surprising how we will achieve that.
There’s another angle worth considering: some see Vitruvian as an open-source BeOS replacement. But if you look closely, what we’ve actually created is an alternative Linux desktop that uses neither X nor Wayland. To me, that’s the more interesting story, and the one I’m genuinely excited about.
After the pilot release, we’re planning version 0.3.1 shortly after, which will include many missing components and bug fixes. By 0.3.2, we hope to have a self-hosting system. After that, the path leads to 0.4.
Q: Looking ahead: how large is the Vitruvian team today, and for those interested in contributing, what’s the best way to get involved?
The Vitruvian team currently consists of three members, one of whom is working on the ARM port. We’ve also had some random contributors, which is encouraging given how low-profile the project has been until now.
We’re looking to connect with people who have a strong interest in the BeOS world but haven’t been able to engage deeply because current alternatives don’t fully meet their needs. We’re also interested in people drawn to alternative Linux desktops, and hardware enthusiasts, especially those exploring alternative computing platforms like ARM and RISC-V.
We have many ideas in development right now that just need time, commitment, and resources. The best way to get in touch is through our website, Telegram channel, or GitHub page:
We’re building a complete infrastructure with repositories and other resources, which means we’ll need community support. We’ve invested substantial effort into this project and stayed low-profile to ensure we solved the technical challenges properly. If you’d like to support us, donations are deeply appreciated:
https://wiki.v-os.dev/docs/reference/donate
The ideas we’re developing right now span several areas. We’re working on ARM support and system-level support for NPU cores because we believe alternative computing platforms deserve a real alternative. We’re going to make the system officially self-hosting soon, Vitruvian will build itself. Even the buildsystem is much more than a weekend project itself. Our buildsystem is now capable of building full ISO and raw images that can boot the desktop. It’s almost a full replacement to what existed before, built from scratch with Vitruvian’s needs in mind. We’re also thinking about the ecosystem: what applications would feel native to this environment? What would a Vitruvian-native web browser look like, or email client, or development tools? Those are the conversations we’re having. If you’re interested in any of these threads, reach out. We’re genuinely looking for people who understand what we’re trying to do.
Thank you for the opportunity to share this journey.
About The Author
