Keeping binary compatibility for SoundPlay? Really? Okay, let’s not improve MediaPlayer and introduce addon support or something like that to bring its functionality closer to better parts of SoundPlay. Let’s not do that, it’s better to remain in the abandonware nostalgia bubble for what’s left of the decade. That will surely bring more developers, donations and user interest to Haiku…
5 Likes
Adding a tidbit related to 32-bits and latest generations of CPUs.
Neverware,which has been putting a distribution of ChromeOS called CloudReady in 32 and 64 bit variants, has encountered issues with its most recent 32-bit beta release on Braswell and Kaby Lake based systems ( https://www.neverware.com/blogcontent/2018/2/27/update-cloudready-home-edition-v631-available-on-dev-and-beta-channels ). Essentially nothing is displayed on the screen!
Just a heads-up about potential issues with maintaining a 32-bit environment with latest generations CPUs.
In the other hand i suggest haiku should start to receive monero donations and bitcoins, is q good amount of easy donations
Not enough people know about APlayer, it seems. It already has add-ons support and a lot of other nice features, and it is open source. However there is no development effort besides the little bugfixing I could spare the time to make. Help very welcome!
1 Like
Totally. Let’s lean back and erect some awesome strawmen instead.
1 Like
MediaPlayer is no SoundPlay and has issues that don’t exist in the latter. Until there are native apps worthy of replacing the ones coming from BeOS that already have the mindshare of end-users who expect Haiku to support them, then you’re not going to convince folks otherwise. As far as I’m concerned the Haiku end-user demographic accounts for users that came from BeOS (like myself) and users who have never heard of it. I think it would be unwise to abandon the BeOS side of the community as folks would probably just give up on Haiku knowing that the original intention of the project was not fulfilled.
As for SoundPlay and being abandonware, let Marco N. make that call!
1 Like
The problem is Haiku has already surpassed the goal of parity with BeOS R5 so long ago, it’s impossible to know when it happened.
It has MORE features than R5. It supports NEWER hardware than R5. What does Haiku NOT do, that R5 CAN do? Honestly. If devs had stuck to creating an exact clone of R5 in Haiku, I’m quite sure it would be a moot point today… fulfilled long ago.
But what has happened is “this” got added and “that” got changed and “these” got tweaked. And along the way, “this” stopped working and “that” got regressed and on and on and on.
I would propose two teams. One devoted to JUST Haiku R1 (once it meets all criteria for being as functional/stable as R5, then it’s DONE) and one devoted to JUST Haiku x86_64 (let IT be the one that may never see “R1”, because of endless upgrades and improvements and such).
If 100% R5 binary compatibility (able to run any and all BeOS apps you throw at it) cannot be achieved in Haiku, for whatever reason, then either downgrade it (take out whatever “newer” (better than R5) stuff has been added, that is breaking it from fulfilling that goal) or decide that newer features and less compatibility is an acceptable trade-off and throw it to the masses as complete. I’d also propose that some end users be assigned to torture test Haiku 32 (with an old system running R5, for comparison), to make sure it’s just as stable as R5, in the end.
If newer hardware is causing problems, then stick it on older hardware. The same system, preferably, for a dual boot environment or two separate, identical systems, if possible. Really devote everything you can to finishing R1 and putting it behind you.
[I had a Pentium III system (back when they were modern) that ran R5 beautifully. I could start putting feelers out to get another one for this purpose].
Then put all focus into Haiku x86_64 and HAVE FUN!!!
1 Like
Maybe you should think differently, because there is an institution that uses haiku. TuneTracker is the only remaining company that relies on BeOS, today Haiku. Their software should definitely remain functional. Here you should hail a good cooperation.
Or have they already switched to another system? At the time of alpha 4, they offered an extensive haiku version (http://www.discoverhaiku.com)
1 Like
Is more slower than beos and dont have input with the dr iversfor my sound card at least.
They are still running Haiku last I heard. IIRC, Dane posted on here a while back asking about motherboards.
Lack of speed is due to bug-checking routines or something. If your sound card works perfectly in R5 but not Haiku, then that is a problem. But one borne of not enough driver support (driver code incomplete) or too much (driver code is from elsewhere (BSD or other) and no longer supports your sound card)?
If Haiku is putting files in places (directories) that BeOS didn’t, then that could cause problems. Also maybe directories have changed (name) and the driver doesn’t know where to direct its input/output?
Lotsa possibilities…
I advice all who write at this thread and are not software developers to stop doing technical suggestions. It sounds terrible, really.
“This way is faster than that way” - how did you measure this?
“This goal is easier to achieve than that” - did you try it?
Please, understand that Haiku developers have exactly the same wishes as you to make Haiku R1 Beta and then Haiku R1 release ASAP, and to make it sustainable in long term. But they also make some plans and their estimations and priorities are based on more credible knowledge.
If you have technical skills, please write the code and try to fix the bugs. This is the most straight way to make the release happen soon. Please do not try to influence the development and / or developers. It is very frustrating!
4 Likes
I do not agree with you. And I do not understand what is frustrating in what we doing here.
About technical suggestions: If no one gives some better suggestions, than it is best what is.
If some one can think, he can make good suggestion, because world is different and people are different and points of view are different and ideas that can be produced are different, and no one knows everything about everything best, developer or not. More good ideas — more posibilities.
And here not some army authoritarian structure, everyone can say what he want, please, do not say ‘shut up’.
2 Likes
I didn’t say ‘shut up’. On the contrary, please MAKE GOOD SUGGESTIONS in domains you are competent. The only idea I insist is: if you are NOT a software developer (to read: technically incompetent), please do not make technical suggestions.
And of course, I didn’t want to say, community has nothing to do to influence the development / developers. I only made this remark in context of influencing technical decisions, which are always carefully weighted by the develops and communicated to the community.
2 Likes
OK. Where you seen here technical suggestion for software developer? I don’t.
Give some example.
1 Like
I would add, that a suggestions of strategies for software development are not technical issues for software development. You do not need to be software developer to understand which software you need and which you do not, which software is new and which is outdated.
1 Like
Here are some technical suggestions done against the agreed plan for Haiku R1 Beta and Haiku R1 release:
Put yourself in place of developer who makes a very hard job doing such a complicated product as an OS, gives it for free, because enjoys the way it acts, and hears such a comments!
4 Likes
I am not a Haiku developer, but I am a software developer. I strongly disagree with you. A software user estimates the time / effort in terms of the number of bugs, a software developer looks at the difficulty of bugs. A user asks: “When will the bug X be fixed?”, a software developer asks: “How to fix the bug X?”. A user asks: “Developers, why don’t you listen to me?”, a software developer answers: “Dear users, please learn to file a bug with relevant information to get it fixed!”
I can continue with such examples. But I stop here. The only idea to add is: normally in commercial software industry the customer complain is not taken in consideration unless there exists an official customer request about it. This request is analyzed by the developers and if it was a user error, customer pays for it and software doesn’t get changed. If there is a software error, it is considered for fixing, with estimation about when it will happen given by developers. If this change is outside the specification signed by customer, he pays for it. And when customer pays again and again, he usually calms.
I have a project at sourceforge.net, which uses some library. When I found this library cannot do something, I opened a bug about it. Additionally I try to prepare the fix for it, which eventually will be merged in the library for all who use it.
4 Likes
Hey, leave me out of this! My comments are different! So radically and completely different… that no one… could… possibly… make any… rational… com…par… ison…
Oops. 
I included your comments not only to show that you make a technical suggestions, but that your comments can discourage developers for no good reason. The Haiku developer’s team puts priority on what is NEEDED for the project more that you can imagine.