Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

VitruvianOS – Desktop Linux Inspired by the BeOS

v-os.dev

Post reply on HN
Print view View original

221–230 of 234 posts

Re: VitruvianOS – Desktop Linux Inspired by the BeOS

#221

Post by worthless-trash »

numerio wrote: post #73
worthless-trash wrote: post #41

Earlier quoted context omitted.

IIRC the realtime patchset that RHEL maintained in its own branch/tree was upstreamed last year. I don't think it makes sense for desktop applications, it may make sense if sound latency is a priority but even then stock kernel delivered lower latency in many cases.

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,…

Can i take a moment to thank you for working this project. I wont pretend to understand the mammoth undertaking to get this to the state that its in. Good work.

Re: VitruvianOS – Desktop Linux Inspired by the BeOS

#222

Post by jcgl »

smallstepforman wrote: post #219
AlecSchueler wrote: post #33

Earlier quoted context omitted.

Presumably there's a lot more modern software written for Linux which you'd end up running through a compatibility layer from Haiku? The better option seems relative. I could be misremembering how Linux programmes are handled on Haiku though.

In Haiku windowing system, each app window gets its own thread so dialog boxes run in a different thread to the main window and a different thread to the core app. In Linux, all windows share the same message loop thread. A simple port reveals threading issues in Haiku which dont exist on Linux. To work around this, all window messages in ported apps are marshalled to execute sequentially. Small additional overhead,…

> In Linux, all windows share the same message loop thread.

I'm no expert, but aren't you just talking about Xorg here? As far as my limited knowledge goes, there's nothing inherent in the Wayland protocol that would imply this.

Re: VitruvianOS – Desktop Linux Inspired by the BeOS

#224

Post by blacklion »

jazzyjackson wrote: post #218
blacklion wrote: post #167

Earlier quoted context omitted.

I think, in case of e-Ink photo is much more informative, as screenshot takes data from frame buffer and didn't take screen technology in account.

:P lol indeed a screeshot would be full color Perhaps I can place the monitor on my scanner and take a “screenshot” that way xD Re: refresh rates I can’t find a good stat with a brief googling but it’s a Boox Mira, E Ink VB3300-NCD You can tolerably watch video so somewhere north of 20fps but there’s ghosting. A friendly button on the front of the display is there to do a hard refresh if the artifacts build up too mu…

I've tried smartphone with e-Ink (mostly for motorcycle and hiking navigation, not as daily driver) and know this problem — it is impossible to share this experience via screenshots or screen recordings :)

Re: VitruvianOS – Desktop Linux Inspired by the BeOS

#225

Post by lproven »

prmoustache wrote: post #103

Anyone remember BlueEyedOS? It had exactly the main goal, building a beos compatible OS on top of the Linux kernel.

A later successor was Cosmoe:

https://gitlab.com/haydentech/cosmoe-classic/

This has evolved into a new UI layer for Wayland, on top of Linux...

https://cosmoe.org/index.html

I wrote about it last year:

https://www.theregister.com/2025/06/25/cosmoe_new_cpp_toolki...

Re: VitruvianOS – Desktop Linux Inspired by the BeOS

#226

Post by lproven »

danwills wrote: post #39
aaronbrethorst wrote: post #10

Vitruvian asks a different question: what would I actually want to do with my computer that I currently can’t? Only be able to drag a window around the screen from the top left corner

On many Linux desktop environments it is the default - or can be configured: To hold the Windows Key ('meta') and left-mouse-drag a window around from _anywhere inside the window_! No need to get the mouse into the 'title bar'! Additionally, meta+middle-mouse-drag allows one to resize a window from anywhere in the whole window!! (it chooses the closest corner when the drag starts) and this, being able to resize a win…

> There's a Windows app I used to use that supports the same kind of thing for Windows

Taekwindow:

https://ttencate.github.io/taekwindow/

I rarely use Windows but any box I do need to use for a while, I put Taekwindow on it. I only want the Linux feature of middle-clicking the titlebar to send to the back, myself, I don't want or need moving or resizing, but they're there.

Re: VitruvianOS – Desktop Linux Inspired by the BeOS

#227

Post by lproven »

clayhacks wrote: post #38

Ok maybe I’m too young, but what is BeOS? Everyone here is linking other alternatives, but no one’s linked to the original BeOS. Or is it gone now?

> Ok maybe I’m too young, but what is BeOS?

Does this help?

https://news.ycombinator.com/item?id=47520510

Re: VitruvianOS – Desktop Linux Inspired by the BeOS

#229

Post by numerio »

rubymamis wrote: post #122

Can someone list what are some cool/novel BeOS features that other OSes didn’t have at the time and maybe still don’t have?

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

Re: VitruvianOS – Desktop Linux Inspired by the BeOS

#230

Post by numerio »

pjmlp wrote: post #106
hnlmorg wrote: post #65

Earlier quoted context omitted.

How strictly do you mean “UNIX clone”? Because Linux isn’t strictly UNIX. But then at the other end of the scale, BeOS was also partially POSIX compliant and shipped with Bash plenty of UNIX CLI tools. Perhaps it’s better to play it safe and just run DOS instead ;)

It certainly is, what it is not, is a derivative. BeOS on its final commercial version certainly did not allow to compile UNIX applications, beyond the common surface that is part of ISO C and ISO C++ standard library.

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.
Post reply on HN