What about bounty? 3D acceleration bounty?


#61

Honestly, how BeOS handled packaging was fairly slick. It was designed to be simple, effective, and allow for a better system to later be implemented. If we had stuck to that philosophy, we wouldn’t have the current RO, forked up file system that we have now. It’s quite possible that R1 would be already in the past, and a better PM and hardware acceleration already be in beta. All we can do now is learn from the past.


#62

Yes but we would have dependency hell… which is not a problem with the new package management.


#63

I’m with you on that. For what it is, it’s my favorite package system on any OS. I still think it’s a good learning point on what focus shifts can cause.


#64

Which is one of my favorite parts of it. The oddities I can live with until a later date. They can be resolved, but not without unnecessary delays in the schedule. In any case, I’ll remain patient for acceleration. It will be nice to see a well planned and implemented system.


#65

If only we had a dotcom mogul funding Haiku. We can dream, right? :joy:


#66

Problem is, what’s the focus? “Haiku is a Desktop Operating System”? Is that really a focus?


#67

As said in the homepage?

Haiku is an open-source operating system that specifically targets personal computing. Inspired by the BeOS, Haiku is fast, simple to use, easy to learn and yet very powerful.

These sound like sane and worthwhile goals in the modern days. GNOME is trying to be both desktop and mobile apparently, so in terms of free software operating systems for personal computing / desktop computers, there is not that much choice. This is what makes me think Haiku has a role to play in computing.

I see a lot of debate about “focus shifts”. We already made one back in 2010, and I think this is when this goal stated on our homepage was set. Note that it is not anymore “Haiku is an open-source recreation of BeOS R5”. We already understood, back in 2010, that this was not going to cut it anymore as a project vision. So now, Haiku is only inspired by the BeOS. The fact that we keep binary compatibility with it is not part of the project vision anymore, and is kept because 1) it is already there and not too costly to maintain and 2) it is useful to run some old apps and to test regressions from BeOS.

As for devs waiting on 3D acceleration, releases or whatever: I don’t care about developers who wait and do something else. I care about people who are already here contributing, or really motivated to start.

Because these people who just wait for a release will do something like: “oh cool, finally an Haiku release, let’s install it. Oh, but it doesn’t have $X yet, not suitable for my need. I’ll try again in a few years.”. And when you implement $X, they will say “it doesn’t have $Y”, and so on.

The proper attitude is “It doesn’t have $X yet, maybe I should try implementing $X”. Now we’re talking and there’s some hope to get a new contributor to Haiku. So, the lack of 3D acceleration should be attracting devs interested in implementing that, right?


#68

I still think Haiku should implicitly target a more focused set of users. For example, are those users people who use a browser and office suite extensively? Then bet all on that.

When reading that I thought I had my mind farting, because AFAIR, Haiku always was a Desktop operating system:

https://web.archive.org/web/20061004081231/http://haiku-os.org:80/

Let’s see when someone begin to add C++11 features, if it is “not too costly to maintain”. Locked with C++99 it is a bit easy to say. Not to mention a whole lot of other stuff the Haiku API needs to become somewhat modern.

Not with the current flaws in the API. You like it or not, we need to review a lot of things on the light of the 20 years that passed.

I think the project held back quite a few of developers because of sticking to some goals. Those goals were probably right until a few years ago, but now it is time to look at recovering some sane need to advance the system. I think you can have drivers where there’s actually an use case. Linux had a lot of audio drivers thanks to what jack allowed to do. The same apply for a lot of other things. If Haiku at least had a little more implicit goals like “web browsing”, “multimedia”, I’m pretty sure it’d be more interesting to developers.


About API improvements and Media2 Kit
#69

If it’s implicit, that’s not very useful, right?
I focus on my own uses: web browsing, listening to music, hacking on code and doing some electronics schematics, and basically that’s most of it. Maybe the occasional running an old game.

But each of us has somewhat different goals here, and they don’t necessarily conflict with each other. And I don’t think we need more specialization than we already have.

The first release will be an improved version of BeOS R5

So we switched from “an improved version of BeOS” to “inspired by the BeOS”. Isn’t that enough of a focus shift?

As an user of the OS, I couldn’t care less about APIs. I just want my applications to run.

As a developer, I’m fine with the interface kit, it sure had its flaws but we have way around them at least. I’m indeed very frustrated by the media kit API which is currently unusable for my needs (I think it is way too low level and needs too much code written to get anything done). I get away with the game kit APIs for that.

And, the nice thing about Haiku is that I can improve it as I see fit for my needs. This alone is a good reason to continue working on it rather than consider switching to something else.

How so? “the project” isn’t going to prevent people from working on something. You can send patches and they will be reviewed. There are some restrictions, such as “dont break the R5 API”, because a stable API is a good thing. I agree we need to get our R1 out and then we can tell people “dont break the R1 API” and have an R2 API next to it. Which is what you are already doing with the media kit, if I’m not mistaken?

It is a desktop operating system. What do you expect? Of course this includes browsing the web (and we fail to deliver) and listening to music with your computer (and we fail to deliver on most machines for lack of a working hda driver). It of course also includes working on office documents, and we don’t fail so much anymore on that thanks to the LibreOffice port. So things are getting together one at a time but I consider that we are far from this simple goal yet.

Haiku will be ready for R1 when I don’t need to boot a Linux or Windows machine anymore, or resort to my phone for visiting a website. That’s my personal goal, maybe other devs have a different one.

And to get back to the topic of 3D accel, it is waaaay down the list of things I want. Besides the already mentionned web browser and audio, what about dual screen support? webcam so I can chat with my family? MTP so I can transfer files to and from my phone? Working IMAP so I don’t have to ssh to my mailserver and run mutt there?

Well, I have things on my TODO list to keep me busy for the next few years, as you can see :slight_smile:


About API improvements and Media2 Kit
#70

Okay, I get what you mean.

For the other stuff, there’s a natural rejection to renovation in this community. As I already said, it took me countless flames to finally get some acknowledgement from other devs that the media_kit is flawed. And I still sometime have to deal with people that tell me “hey, you can calculate audio latency ahead of time”. Now I will start another topic about why I think Haiku needs something on the line of the OpenBinder.


#71

A release provides other developers a ‘reference (stable/tested) state’ for collaboration, review, and testing.
Also, internal developers know that external people/QA/testers/users are now going to look at their internal work and place judgement (and have flame wars and trust issues).

I think this is where Bullfrog was going in his earlier statements of other’s feelings with not having a consistent release schedule pertaining to Haiku. People lose confidence, or trust, in the Haiku development cycle/release - but that is their prerogative. The true state of things in the Haiku ecosphere may differ from their (i.e. external developers/users) reality on things that matter the most.

As for 3D HW acceleration, this is a discussion going back to BeOS with the ‘roll our own 3d drivers’ versus
ISV-provided 3d drivers. Waddlesplash eloquently explained in his timeline to port a BSD Mesa-related graphics framework strategy to Haiku. Kallisti5 mentioned doing some radeon driver and Mesa git updates as well.

I think the headway on this topic is awaiting the work from those developers. In other words, let us all wait for further instructions… :zipper_mouth_face:


#72

That was never going to happen, 3D drivers have grown in complexity in the past years, the only reasonable thing to do is port mesa, and do so as a wrapper for the Linux drivers as doing anything else is asking to be left in the dust by not leveraging existing work.

The last 3d driver for BeOS was written for fixed function hardware… Modern GPUs arena completely different animal.


#73

Watch out… rabbithole territory. Adjust your observatory eyes towards FreeBSD’s port of amdgpu 18.1.0. An inquiry of provisioning this same AMDgpu driver to Haiku seems worthy of a dice roll. There is also the
expansion of the Mesa port for Haiku to provide support/handling of its additional components (i.e. KHR, GLX, etc) with app_server.

The rabbithole runs deep… resist the dark side…


#74

Not quite… some BeOS apps still won’t run on Haiku without some more fixes needed.


#75

Well the thing I think some folks are raising is wooing potential app developers so we can get more devs developing more apps. If Haiku can’t handle/support the things (like 3D acceleration) that devs take for granted on other OS platforms, it’s really a black eye for Haiku. I get that there is a lack of OS developer resources and can speak for most everyone here that we REALLY appreciate the beautiful fruits of your hard labor. Haiku in many ways is already better than BeOS but it’s not there yet. Still needs more work and polish before R1 stable can be cut.


#76

Some BeOS (as OS) will never run on Haiku, except in emulator. Some BeOSprograms will never run on Haiku if they using some private Api, etc. Try to be clear next time.


#77

You are the one running rabbits…I said nothing of supporting GLX etc… that would frankly be rather silly. Especially when that has been superceded by wayland.


#78

No…the reality is setting expectations beforehand. Be the driver or app conversation on GLX, Vulkan, VDPAU, or whatever - build a wrapper for a framework and then… what? As someone said, it’ll always be something else or a false expectation of what should be versus what is not (or interpreted). Our constructs are different - therefore our expectations will differ without some known baseline to follow in which we can settle upon.

This is explained in Pulkomandy’s commentaries about Web+. What he wants/expects versus others. He moves his cheese based upon what he wants/desires/needs from a web browser/desktop and goes (or is motivated) from there. Since he doesn’t shop at BestBuy, he may not fix issues browsing their web site as it is not his priority (or immediate need). As he and others mentioned, many of us fall into the trap of wanting many things even after wanting the basic thing (aka 3d HW acceleration). The rabbit hole becomes deeper as we then want other things in relation (like a Vulkan driver). So, we have to step back and look at the wider spectrum of what it really takes for someone/people to step up to the plate and swing the bat of resolution.

As for GLX, better to note:(GLX is handled this way/unsupported/not at all for Haiku). I could mention any feature. The point is that if someone expects a 2D/3D driver to function like it does elsewhere, set some expectations for them. Let them know what the main goals are and are not. Some things are not well known to others…

Ok, I’ll digress
.


#79

I don’t really see that as much of a focus shift. Both goals are in line with seeing R1 before anymore major additions, such as hardware acceleration. As I see it, the project is still in line with making a usable modern system. It was postulated that R5 was 20-30 years ahead of it’s time. By that standard, we still have a few years left to go before Haiku would become irrelevant, even if it had stuck to strict R5 clone. I love the system as it is currently, and spend more time as a user in Haiku than as a user in any other OS. Webpositive is my current favorite browser. It does everything I need it to do. I love the fact that I get to use a modernized BeOS with the same basic philosophy. Keep up the good work! That goes for the whole team!


#80

The APIs should just be provided as is with any winsys stuff done internally to Mesa…quit overcomplicating things.