I’ve developed guis in several native and cross platform environments to at least have an opinion on the topic.
Once you code a gui in GTK, you begin to discover new levels of anger (not even talking about setup it, if required). I dont know why someone would use it unless you had an existing codebase and wanted to go forward/update it. If i put some effort on porting Gtk3 is not because i think it’s good, but because apps require it.
Despite liking things like Vala aproach, going with a QT code is much productive (saying as creator and eventually maintainer of QT based apps on my company). The only thing that made it bad was licensing and the company behind it.
On the topic, Haiku Gui could be ported, but has not the back story of documentation that the other two have, have no big foundation behind (Chrome or TrollTech), examples and base knowledge from the developers. Wont get a spot in the dev world without some kind of support.
And frankly, the Haiku native guis look dated, which if you come from BeOs is a OK thing (>>me<<) because it was good in the time, but for newcomers… maybe not so much.
Sure. GTK is a burden. But there’s even people who like to be masochist in using object oriented C. All in all, it is still used in major applications.
Developing in Qt is really nice. And you can get non trivial applications up in a matter of days. It is very likely in the end will become the main linux drawing library, but I think will take a lot of time. Wayland is in fact designed to overcome some of the problems.
To be honest the story of running the HaikuAPI on linux started because I wanted an OS that could handle e-ink screens correctly. I really like to use ereaders, mostly because I’ve become a math addict and download lots of research papers. The main problem however is that most ereaders ship with a ridicolous linux OS, obviously designed so that you buy books from them.
Since on Haiku concepts like animations and compositing doesn’t exist it’d be the perfect fit for this kind of technology. With a reworked decorator and help from the inherent simple design of Haiku, it could really make the difference.
Now the problems, let’s leave alone the fact that Haiku doesn’t run on ARM (which is itself pratically a stopper). I could use an x86 board, but then you’d have to implement things like:
standby support
power management
a decent e-ink driver
3G/4G drivers
…
All things that depends mostly on the kernel. It is obvious that going with the Haiku kernel is unfeasible. I can use Qt Embedded, and develop an OS on top of it. But that won’t be different than taking the Kobo software and forking it. And I am trying to do something different. Since I am an Haiku developer, like a lot the Haiku design and philosophy, it is obvious that the logic consequence is porting parts of Haiku on top of linux. This is hobby after all.
I think I’ve started to see where you’re coming from with your needs. Thanks for the explanation.
Being able to run all the Haiku UI on top of a more up to date and feature-rich kernel would indeed be great. I suppose there’s a couple of big blockers:-
There’s not just the UI API and the kernel, there are services like app_server and the launch_roster in between - would you wish/need to have those run on a linux kernel? If so, how inextricably linked are they to the Haiku kernel?
If just migrating the UI API, is it even useful without the above mid tier set of services, with the Be Filesystem, and other things that make Haiku what it is? (E.g. tiling, stacking of windows, and so on)
Beyond the above technical challenges, would you lose any technical advantages of the Haiku kernel? Would this affect things like Haiku apps’ threading models and responsiveness?
I don’t know many of the answers to the above, but it does sure sound interesting to chat about it.
Actually, the state of GTK on Windows pretty much nails what I think would likely happen to a “BeAPI on Linux” attempt. People will be like “waaah, no native fileselectors? why is the ok button in the left side of the alert windows instead of the right? why can’t I drag and drop colors between Qt and BeAPI apps?”
What makes Haiku work so well for me is not the BeAPI, which is only good but not perfect. It’s the possibility to have this all-over consistency (all apps use the same API, look and feel, etc) and integration (ability to share data (BMessages) and code (replicants) between ALL apps). And you can’t bring this to Linux by adding yet another API to their already very disparate ecosystem.
That being said, I’d love to be proven wrong, just don’t expect me to start working on it at least until then. V\OS is probably on the right track for achieving something, as you have good knowledge and understanding of this.
On the matter of using Qt for Haiku: it is indeed one of the most compelling candidates if we ever were to switch to something existing as a replacement for the BeAPI. However, it would likely need some extensions to completely replace the BeAPI, I think mostly in the low level side of things (remember the BeAPI goes as low as create_area and all these things in OS.h). And, this also would raise the question of wether we use the Qt codebase directly (does it fit with what we want to do? what if we ever want to change or extend it? Would we do to it the same thing GNOME did to GTK3?) or it we reimplement the API using our existing tech (and I think this would be crazier than just working from what we have and putting the BeAPI on par with Qt on the things they get right).
Port it. Don’t port it. It’s fate when done so will most assuredly rest on your shoulders.
Look at the GSOC port of Java 7 SDK, about a 90% completion effort due to time. It’s been code rot since, dead in the water, no v8, no v9… There were years and years of “we need Java!” prior to it and looked what happened.
Give everything of yourself and expect nothing in return. I think that’s what you can realistically expect…outside of kernel or device driver work.
You’d get more usefulness out of porting the BeOS API to C# on Mono / Microsoft Windows. Then, it could come full circle back to Haiku if there’s ever a successful Mono port to Haiku.
As for really useful ports to Haiku, Mono and DrRacket would be my #1 and #2. DrRacket is just plain awesome. OpenJDK 8/9 would very be useful for the non-Java / non-GUI language aspects (Clojure, Scala, JRuby, JPython, etc)
There is always a risk of getting code rot in any sort of project or porting effort. If any of the patches for the port are never maintained/upstreamed and tested or the original maintainer left with little to no documentation then things start to go downhill from there. This isn’t exclusive to the Java port.
Besides this maintenance issue, we have on-going work to bootstrap the OpenJDK port with the 32 compat-layer by @korli for Haiku 64 bit. It can run 32 bit Java apps so far, but should be able to cross-compile itself from 32 → 64 bit for a native build or higher versions.
Well that depends if either you or some other interested contributors join in the effort to maintain the port. Perhaps you will be interested in helping to maintain this existing Mono port for Haiku then.
Well that may be the case but if it allows some Haiku developers to write a portable app instead of using QT,then it will have suceeded.
QT has already succeeded on Haiku by boosting the number of available professional quality apps… and having a portable BeAPI may be the next step by allowing people to develop professional quality apps on Haiku without fear of being locked in. To do that currently you just can’t use the BeAPI at all.
There has been little reason to upgrade past Java 7 so no real push for it. Very few applications have required it though I suspect that is changing slowly.
It depends (as always). There are parts that make absolutely sense and others that doesn’t at all. In the middle there’s the stuff for which it is merely a development decision.
For example let’s take the app_server. I think it is basically the essence of the whole BeOS spirit. There is not a big link with the kernel, if you count out the kernel_kit, in fact I have a version of the app_server which runs. The main blocker is the drawing backend. Luckily, the app_server does indeed allow to create more backends, so it doesn’t need big architectural changes.
One alternative view about the app_server would be the possibility to port it as a wayland compositor alongside the other libraries. This is a less trivial approach and would probably need many structural changes to the code.
The launch_daemon is somewhat equivalent to the old linux init system. But systemd is much more complex and does things which we probably don’t want in a Haiku-style system. In that case I’d probably use the launch_daemon.
Another interesting part is the package_kit, for which honestly I have not idea of the implications in porting it. Mainly because it is a relatively obscure and new part of the operating system. In that case, we’d probably port the packagefs on linux. In that case, we’d have to port the Haiku kernel fs syscalls or rework the kit to use that of linux.
The general design of Haiku is very good regarding the link between user and kernel API. In general it is possible to take a single component and only port the needed syscalls.
If you want a rough idea for the kernel API that I needed to make the app_server run you can look at the libroot_linux in the V\OS source:
In general, I’d look at porting the majority of the Haiku stuff. So you can imagine taking a nude linux kernel and building things up. Of course, there are things to evaluate, i.e., dbus.
The Be Filesystem was a good exercise at getting the best from the Pentium 3 era. Nowadays, it is obvious certain services shouldn’t be placed in the kernel. Note that this is not a my idea, but you can read similar considerations from the Dominic Giampaolo (creator of BFS) and axeld (OpenBFS) work. I’d not use BFS as there’s not really reason. The only non trivial problem is that linux doesn’t support opening files by inode for security reasons, and the Haiku kernel does that only for compatibility with BeOS.
In the end, you’d get the same filesystem features you have already on Haiku, except that attributes and queries are provided by an index_server.
No. I am pretty sure you’d have an increased responsivity if any. The Haiku kernel is good because allow us easy BeOS compatibility, and it is after all designed to run the Haiku userspace. However, it lacks optimizations and flexibility. So the balance is never going on par compared with something like linux. So, from a technical perspective, linux and the Haiku kernel are really equivalent. You’d have to use the most useful of the two.
Hasn’t @PulkoMandy previously mentioned in some other topics that everything is currently in debug mode until R1, which incurs performance hits? It’s probably not a good idea to compare the performance differences between the Haiku and Linux kernels until then. Someone please do correct me if I’m wrong in a certain aspect or have misremembered something related to this.
That’s right, but even in release mode the Haiku kernel will not reach the speed of the Linux one. This is not where we shine. What makes Haiku feel so reactive is probably mainly the use of threads (lots of them) with a system-wide agreement on how to set thread priorities (there are defines for thread priorities shared by all apps), allowing the scheduler to prioritize user interactions above anything else.
There are two key points to this:
Mainly, the use of the BeAPI for all (or now, only most) of applications, making sure threads are created with the correct priorities by default (for example a BWindow thread will have higher priority than a BApplication or a generic BLooper). This is probably not going to happen in GNU/Linux as long as they keep providing different GUI frameworks and APIs. It may work in Barrett’s V\OS however, if that gets to run mostly BeAPI based code.
And probably a little less relevant, the scheduler algorithm is tweaked for our use case (fast user interactions) whereas the scheduler in Linux tries to handle other cases as well (servers, embedded devices, …). The result here is that the Linux kernel makes different compromises, it is faster overall, but sometimes it makes the user wait to finish background tasks faster. This may also be something V\OS could improve upon, either by tweaking the Linux kernel configuration, or by patching the code if nothing else works.
I will not comment anymore on the topic of Haiku vs Linux in terms of performances. But I strongly suggest people to look at things considering the Be Inc. viral marketing that still affects us.
I think a lot of that makes sense with the possible exception of completely dropping meta data in the FS… counter example is Anakondi/Neponunk/Baloo in KDE… which for ages was horrible Baloo is supposed to be better but who knows. And KDE tends to have the manpower to make things like that work… but it just absolutely sucked performance wise sucking the life out of your PC.
I don’t know how you would support live queries without either incurring a cost at the filesystem level or having a scanning/file watching daemon (bad idea IMO). Doing it at the filesystem level allows you to cleanly make guarantees about quality of service.
One thing Haiku developers should also be careful of is “works for me”, say for example all the dev’s have SSDs now there could end up being unnoticed pathological cases on HDDs (like Windows 10). A similar thing seems to have recently happened in Haiku with HaikuDepot with a non English locale… just because it was untested where it would take minutes to run.
I have my personal user experience to back what I said. The kernel is obviously slower, yet somehow the OS manages to feel more reactive and never lags behind me. I think you agree on that?
I’m very interested in V\OS to see what happens with a kernel swap. Maybe it will be even faster. Maybe not. There is only one way to know.
Attributes themselves are going to be placed in the fs of course. It is all the database thing which is not good to be placed in the filesystem. It is because makes hard to develop non-trivial querying and text indexing, and it is because expose the fs in a number of problems with corruption and security.
If the attributes are placed in the fs then the index_server would handle only the queries. Yes, there will be a little cost, but nothing that I think can be noticeable on modern PCs. At least, OS X spotlight doesn’t seem to work that bad and other than being developed by Dominic Giampaolo, the design is very similar to what I’d do on Haiku.
And on topic, I notice that finding attributes aren’t as instanteous as the Be books would have me believe. And despite the fact I can search attributes, I can’t look inside files with Tracker (which is why Haiku has TextSearch). After indexing the disk, search on Panther (before Spotlight) is pretty darn fast on a 466 MHz G3. Spotlight on Tiger - Mavericks was excellent and quick with enough RAM (and a fast CPU). On slow, old Macs, like G3’s, it’d have to be disabled to get better speed. But the point is, it worked. And a heck of a lot better than Vista. Sadly, Spotlight has gotten ever slower since Yosemite redid Spotlight and bloated it to heck.
Over time I think it is obvious this metadata feature is not something the user is normally willing to use. Mainly because you need apps to properly support it. I think Spotlight was created on the wave of the popular BeOS features and right now is not perceived as something high priority.
Additionally spotlight work like a full text search engine. If we were to add that functionality to Haiku performances would be similar. And, on the other hand, if we were going moving out of the fs the querying (without indexing) the difference would not be perceivable.
