[captainbland]

That's a really impressive achievement I think, those are complex applications running on complex stacks. It's certainly a big step in the direction of making Haiku a system that a developer could plausibly run for the development of cross-platform applications. This coupled with the Libre Office port last year means there's a pretty strong selection of applications for it cropping up.

[Apocryphon]

I wonder if Valve has hackathons and if the Proton guys want a new challenge.

[joshumax]

I worked at CodeWeavers during the development of Proton, and one of the biggest hurdles for getting Wine (and therefore Proton) running on Haiku is the memory layout of Haiku[1] and subsequent failures of mmap(). I have a Haiku port that runs basic applications out-of-tree, but many Win32 programs crash on Haiku still.

1: https://wiki.winehq.org/Haiku

[waddlesplash]

The memory layout of Haiku x86_64 is identical to that of Linux. Perhaps you should try there first?

At any rate, we'd love to at least have your patchset in HaikuPorts, even if it's not quite ready for prime-time yet.

[mike_hearn]

You could just bypass the preloader completely. It exists only to work around the Linux ASLR implementation which would otherwise tend to place DSOs randomly in the address space, potentially overlapping regions that Windows keeps reserved. If Haiku doesn't implement ASLR, or lets you easily disable it, or alternatively would accept patches to ensure its address space layout is always Win32 compatible (better!) then the preloader could be disabled.

However if mmap is more significantly broken then Haiku needs work - Wine does need the ability to map things into the address space at the requested locations and actually get it.

[waddlesplash]

Haiku implements ASLR but there are ways to disable it. They are undocumented private APIs, though.

mmap on a fixed address should work just fine, unless the address is outside the normal range or in an already mapped region, which seems to be a problem on 32-bit systems. I think there are some emulators we have ports of which already use MAP_FIXED quite a bit.

[agildehaus]

As far as I'm aware, Haiku doesn't have hardware 3D acceleration of any kind. So, please!

[chaz6]

If you can now run your development tools on Haiku, what would it take to make Haiku a server platform for running your server-side applications?

[gecko]

Haiku is a single-user system, so effectively any privilege escalation gets you root. That's enough right there for me to keep it off a server.

[waddlesplash]

Yes, while we need to fix the privilege issues and add proper user segmentation, we don't ever intend to aim at being a server OS.

[ec109685]

Isn’t the definition of privilege escalation going from non-root to root or did you mean that any RCE on an application gets you root.

Nit picking comment aside, I wonder if the fact that it is single-user was one of the reasons Apple did not go with it.

[saghm]

On a multi-user system, you could have one non-root user gain privileges granted to another non-root user, which I think would still be considered a privilege escalation; e.g. before the escalation, I only have access to my own home directory, but afterwards, I have access to both my own and yours.

[tonyedgecombe]

Hopefully not, it's better they focus on doing one thing well.

[tqh]

We only have plans for a desktop OS.

[badsectoracula]

But what is the point of using Haiku if you are going to run (desktop) Java applications? The main appeal of it is its native API, use of multithreading everywhere and how integrated the applications are. If you are going to treat it as just a window manager with a different theme, then why not just use XFCE - it even has a BeOS-like theme.

[pjmlp]

Which happens to be the fallacy of GNU/Linux desktop as well.

The beauty of each desktop centric OS is the whole platform, the set of SDK languages, the respective frameworks for exposing the OS and hardware features that make the desktop experience unique, and IDE developer experience.

If it is to run desktop agnostic apps, then anything can do.

[mhd]

There's always been some leeway in that. Both the original Mac OS and Windows had a variety of languages targeting it, but they tended to strive towards emulating the core SDK experience (if they weren't a wrapper around it).

Unix had it different with there being no core experience in the first place -- X11 being a glorified terminal multiplexer plus xeyes. Whether it was the commercial Unices with OpenLook/NeWS vs Motif/CDE or later Linux with Qt vs Gtk. Not that there wasn't a chance -- at one time Motif won over the commercial sector and if it would've been available with the same license as Xlib/Xt, GTK would've never been developed.

But that seems to be a thing of the past. These days the web forced us to give up all platform-specific UI expectations -- heck, any expectations of having a proper UI in the first place. And thus applications are all over the place, Electron being just one particularly heinous culprit. Material UI on the desktop. Plenty of applications starting up web-based interfaces in the browser.

On the one hand, as you say, this doesn't make the particular desktop matter anymore, it's more a vehicle of getting your wifi driver to work properly and load the browser. So one could use Linux or even Haiku without any big losses. On the other hand, if everything's pastel-colored oatmeal, there's no big benefit from a neat, unified, C++ desktop experience that BeOS was aiming for.

If you want a vision of the future, imagine HTML stomping on your face -- forever.

[pjmlp]

Hence the opinion Steve Jobs had about UNIX, NeXTSTEP's POSIX support being more geared towards bringing software in and win DoD contracts than anything else.

I don't need such vision, it is how it would look like if all OSes happen to jungle browser instances, ChromeOS style, while a big chunk of applications runs on someone else's computer, abstracted via language runtimes.

The return to mainframe's timesharing days and very sad outcome for desktop computers, with the minimum experience common to all vendors.

Graphical APIs not able to take advantage of hardware, hardware support that takes years to have minimal APIs, drawing UIs pilling divs customized with CSS and JS to mimic visual behaviours.

[repolfx]

It's not a pretty vision of the future but maybe there are ways to escape it.

The reason apps all went cross platform is that desktop operating systems stopped innovating. Which is the desktop platform with the most new native apps, where developers take pride in making non-cross platform experiences? MacOS for sure. Which desktop OS has been consistently the most innovative over the past 20 years? MacOS!

Haiku running IntelliJ is technically interesting, but ultimately as a user I don't understand why I'd want to use Haiku. BeOS may have been innovative 20 years ago but it's a dead OS that hasn't changed in decades. May as well run IntelliJ on any other platform, then.

I think the desktop can be great again, but it will take a new generation of developers with new ideas about where to take operating system technology. I also tend to think that whoever tackles that problem will probably tackle it by writing a cross-platform app runtime that slowly expands to become more and more of an operating system until the actual OS is indeed, just relegated to providing some drivers and bootstrap code. But the actual UX will be defined entirely by that environment. Sort of like how Pharo gives you a full blown desktop environment when you start it (but I'm not arguing for Smalltalk)..