Haiku almost-monthly activity report - October and November 2019 | Haiku Project

The last two months have been quite busy for me and I had no time to write up a report. Remember that everyone is welcome to contribute to the website and if you wand to write the report from time to time, this would be much appreciated, by me because I wouldn’t need to do it, and by others because they will enjoy reading things written with a different style and perspective.

This is a companion discussion topic for the original entry at https://www.haiku-os.org/blog/pulkomandy/2019-12-05_haiku_monthly_activity_report_-_november_2019/

As always, thank you for busy autumn work and for keeping us informed.

All these changes in the previous months are looking so much promising. I hope Beta 2 will be out soon.
All of you guys are doing a very good job! <3

Always great to read another Haiku report :smiley: Please keep doing these, guys! Anxiously waiting for the arrival of R1/Beta 2! :smile:


When the radeon_hd driver works four x86_64 on my system. It will be very good to try install and use it. :frowning:

did you open a bug at dev.haiku-os.org about your problems?

Yes , there are various bugs, the most interesting is one bug with something related to atom, bios , which i suppose is my problem :frowning: sadly

Prosze o jakiś kontakt prywatny, chce troche pozmieniać terminal, w dobie powerline i innych wygodnych rzeczy, ten program jest zapuszczony. Ale sam nie dam rady, potrzebuje pomocy.

*Moim zdniem należy wyodrębnić menadżer okien i przenieść go do linux-a. Spowoduje to zwiększenie ilości programistów pracujących nad projektem i zwiększeniem ilości użytkowników umiejących odnaleźc się w systemie. *
Jest wiele rzeczy, które w końcu można by dodac ale nikt tego nie robi bo programistów jest mało. /pl

In my opinion, you need to extract the window manager and move it to linux. This will increase the number of programmers working on the project and increase the number of users able to find themselves in the system.
There are many things that could be added in the end but nobody does it because programmers are scarce.

? why? It is Haiku… nothing to do with Llinux!?
Which project do you mean?

You are not the first one who had this idea, so if you check the earlier forum topics about this you will find 2 answer:

  • The developers understands, that the users wants everything and want it yesterday, and they understands with the linux kernel the development would be much faster, but they either have no interest working with other kernel or they want an own OS where they can change everything they wish, unlike with 3rd party kernels
  • or they says: ok, we can talk about it! Haiku is open source, if somebody interested, can extract the gui code and make it working on any kernel. Do it, make a PoC then we can talk.

Right on. Someone can’t just “extract the window manager and move it to linux” as quoted. There’s really only two routes I see that someone can go.

– The first path or approach, tried by the Cosmos and BlueEyedOS developers, was (far as I know) to provide an abstraction and/or compatibility layer between Linux and Be applications. Personally, I believe this in 2020 to be a waste of valuable time and resources to carry out both because BeOS was 19 years ago by now and more importantly because Haiku already provides an open source environment to run BeOS applications (in its 32-bit edition). It would be impressive for a person or team to get classic Be apps going as is on Linux, but in the grand scheme of things, the workload involved in getting both classic Be and native Haiku applications to work flawlessly with Linux would take dedication and time, and at least two projects have already tried. It could be done (on the Intel side), however, but again, my honest outlook is… why?

– The second path or approach, somewhat tried by myself, was to try to have an accelerated Haiku VM on top of a Debian distribution as part of the “Couplet” edition of the failed Poem project. Of course, the whole project caved on itself as it tried to do too much without QC or a solid roadmap that went beyond dreams and promises on the blog… but that’s another point. The main thing I want to mention here is why the Couplet edition itself failed, and that reason is that it’s just not enough to just throw a VM on top of a Linux distribution, give the desktop a coat of blue and yellow, and call it good. In order to really do this second method (well), what someone would realistically need is something that would work with it. In other words, in my humble opinion, this would be the way forward if any hopeful developer was to choose Linux as a kernel/foundation for a Be inspired or Be-like OS:

  • Wrapper for vintage apps. To me, (and I could be wrong), but I believe that if a developer or dev team is serious about creating a Be desktop on Linux, they will have to build a shiny new desktop environment that isn’t a recycling of current Gtk or Qt enviroments, etc. Why? For several reasons (which are part of the next point) but also because the file manager will have to work like Finder does with Classic in Mac OS 10.0-4; when a vintage Be app is launched, the user will either be automatically launched into that environment (or be asked to). And the rest of the environment will need to center around this principle. It’s there to be a Be inspired desktop unique to itself, not yet another Linux DE with a theme pack.
  • Such an effort will also need to move beyond BeOS applications. Yes, really. People here will think I’m insane on this point, but here’s my reasoning for this second point. Macintosh is my #1 favorite (Be/Haiku is a close #2 for me; both are really cool systems), and a big part of why with the Mac is because of how well the OS X transition was made. In short, minus all the variations, etc. one could delve into, there were three classes of applications: Classic, Carbon, Cocoa. And on the end of this basic trio was Cocoa. So, if anyone (you, me, or someone else) were to create a BeOS environment, it would have to do two jobs: run classic apps through an integrated VM with acceleration (the easy route I’d prefer, although one could go with integrating BeOS app support in the kernel per route 1), and on the other side, ship with a new, next generation class of applications that would support dynamic user interaction, animation, and a whole new API to bind to. It’d literally be a way to move forward and give a fresh kickstart to the desktop (if one was indeed building a Linux system around it). Without that vision in place, this really is where Couplet failed, and where I believe any Linux-based OS or distro will also fail if it doesn’t strive to be a true Be desktop.

Will I ever work on this? At this point, I can say I both do dream of building this as a proof of concept someday… and also am not sure. And the reason behind the half doubt here is because what I’ve mentioned isn’t easy as it sounds on paper, and would take long hours of dedication and work to make happen for whoever does see the vision and builds it. Again, I really believe it’d have to go beyond recycling and be a new environment in heart and soul.

But hey, to the hopeful Be fans reading this wanting to use Linux: if you have the vision to build a real Be-inspired system using Linux as your base/core, then go for it! I just wanted to chime in and mention it’s not as easy as ‘port the window manager over’ to make it work right.

It’s not just about that.

We could port the window manager to another base. We would get better harware support. But we would still get a lot of the problems Linux still has. You will find yourself messing with udev rules, running GVFS or similar tools to control your network drives and mount your USB drives automatically, there will be no way to route the audio to the correct output, etc. Also, our kernel is designed for responsiveness, our scheduler takes decisions that are finetuned to provide the reactivity you know Haiku for. The Linux kernel is today used mostly on servers and smartphones, both of which have very different objectives. So people spend time optimizing throughput or power consumption, and often this comes at the cost of increasing latency.

So, you would lose a lot of what Haiku is.

Still, if you want to do it, sure, go ahead. But telling us what we should do in our life and projects is not appropriate. And you will find out that there is not much to extract. The window manager is tied to the graphics server, and you will be rewriting probably 80% of the code. Some Linux WM however did copy some of our ideas, and that’s a great thing and a more efficient way to achieve what you want. But that is not the job of the Haiku project.


[extract Window Menager]

Why using program from Linux? Because this are easy way to improwe system.
Why using Firefox? Because many people working on program.
This same idea are behing extracting window menager to linux. Not MOVE but share code.

Many developers, users are greatest code.

No problem between Linux to Linux. You does not need to change much in different distributions. But haiku is not Linux. Then you need variables from system side to manage porting stuff, so you need not to do it every time again, but on Linux are many diffent ways available to solve things, thats the right or best way?

This is technically possible. You need to implement Haiku specific API in libroot.so (libc of Haiku) such as create_thread or create_port (documentation). You also need to implement graphics driver (accelerant) and input driver (input device add on of input_server).

Let’s be honest. Nobody using Linux is interested in Yet-Another-Window-Manager. We’ve got enough of them (good ones and less good ones) tailored to the various needs of people. Creating another one in the hope of attracting developers to a foreign OS is simple stupid. Time is better spend working on those parts of Haiku which are still in stone-age since years. “These” things would help attract developers not a transplanted window manager :roll_eyes:


Exactly this. Perhaps those who regularly switch their desktops often on Linux would like to have another Window Manager. But then again, I prefer getting work done and would settle with working defaults rather than sheer customisation possibilities and playing around with my computer.

At least on Haiku, there is always a debate in making certain features as defaults, because of the integrated design of the OS. For example, there are users of Haiku who would prefer window drop shadows to make it look ‘modern’ and those that don’t want this. Personally, I wouldn’t mind having this option in Haiku but not made as the default. It sounds like a feature for R2 rather than Beta 2 and thats down to the decision of the core Haiku developers to decide what are made the defaults.

1 Like

Note that even if app_server will be ported to Linux, it will not allow to run regular X11 or Wayland GUI applications. GUI applications must be ported to BeAPI like Haiku ports to be displayed by app_server. Unlike X11, app_server do not support rootless mode, it manage all screen space and can’t coexist with another display servers.

Drop shadows may be implemented with current app_server architecture. In app_server there is overlay layer that displayed on top of all windows, overlay layer support transparency. Overlay layer is used to display cursor and dragged objects.

Let me use the opportunity to say thanks for your contribution in Haiku, it is greatly appreciated. Keep up the good job!

1 Like