numerio

maybe in early BeOS versions but, BeOS R5 especially with the BONE updates had a fairly decent POSIX compatibility for the time. If you do "ls /" you can see immediatly BeOS has some BSD reminiscence, but certainly it isn't a UNIX OS as in itself.

with BeOS you have instant indexed search, with no index server, and with atomic instant updates (e.g. the same moment you modify a file, the search results update) this is yet to be seen, and we are planning to implement it on Vitruvian

it's like a port of Haiku on top of the linux kernel roughly

BTW because that would not solve any problem for us, the technique you're linking can be useful only if what you want to achieve is binary compatibility otherwise it's useless. That's not really what we are after.

the cli stuff in Vitruvian are exactly the same you'd get on a debian install. So it'd just work out of the box on our OS.

Thank you everyone for commenting! We are going to pubblish small articles on the website to clarify some of the common questions that are popping around. We will also do our best to improve our wording and marketing, thanks everyone for the suggestions and stay tuned!

We have the same IPC that BeOS/Haiku has so it'd run natively, but actually Vitruvian will provide a new modern media framework that is compatible with the old media kit through an external compat library.

It's not that it can't, if you can do something it doesn't mean you should. If we used X it'd be another linux distro isn't it? Part of the fun is to make your own UI feel.

I don't understand the ragebait here. First thing, it's the BeOS GUI that is like that. Secondarily, seems to me also MacOS X lacks a X button? Or did they change it? Third, we can discuss about that, it's trivial to change.

Cheers

it's a little bit more of a compatible layer, it's just a native implementation really. You wouldn't call android a "compatibility layer" right? Kind of a similar idea here.

I won't say you're wrong because you aren't, in fact the system works very well also with non-rt kernels. But the graphical stack is not really designed like the average linux stack, the BeOS is somewhat hungry in terms of timing and I believe our implementation can take advantage of a RT kernel. But if it'd proven unnecessary I'd be 100% for changing it back, it's just a package in our image creation code after all, we don't strictly depend on it.

it's the real app_server running :) so you have everything you'd expect

Yes the UX is virtually the same