QA and stem-to-stern support

Feedback Ideas
#1

In another thread, it was observed that feature creep has started setting in. As part of the cause of the problem with my attempts at adding WebAssembly package support, I’ve decided to start collecting the good ideas that came from the ranting in that thread.

Quality Assurance

Features added distract from the features required to reach release 1.0 of Haiku. There’s no QA team yet so setting up buildbots might be a step in that direction. I know that GitHub’s servers have CI scripting for some instruction sets. What is needed for the rest of the instruction sets?

In addition to building we need some way to quantify how well software works on Haiku once it’s built. A test suite that can report regressions would also be quite handy. What do we have for that?

Supported Platforms for Full Driver Support

If we can get a cheap RISC-V SoC based SBC with a graphics architecture that is documented publicly enough to focus on adding complete driver support, should that be the first buildbot to get stem-to-stern, end-to-end, top to bottom support? I chose RISC-V for the cheapness, availability and low power consumption. @X512 , didn’t you just get one of these on AliExpress for $25? Sounds like a good starting place to me! Also, I have some 32-bit ARM SBCs that don’t consume too much power that might be build bot candidates.

Re: RISC-V boards

Was referring to this post.

#2

???
There is no UI team either, no sound team, no web team. We don’t have teams for anything really… we already do QA, the entire release process is purely for QA.

Automating some testing would be nice maybe.

We already have many tests: tests\src - haiku - Haiku's main repository

2 Likes
#3

Thanks! That’s a start!

Re:teams

Maybe we don’t need a whole team to devote to every aspect of development but I hope that I can help some way and buildbots seemed to be one way.

#4

I am still looking for a list of features we should remove. We are 3 threads into this discussion and no one has named a single one yet.

We already have buildbots, they are at https://build.haiku-os.org

A lot of users-contributors running nightly builds, testing software and reporting bugs.

Adding more architectures is defintely not a goal for R1. We have enough work to do already, and your first step in improving this is adding even more work?

4 Likes
#5

After looking at your buildbot link, it appears you’ve got a lot of architectures running already. That’s good variety, good for many reasons. However, I was after trying to find one solid SBC which all the drivers are guaranteed to work. After looking at the RISC-V MangoPi, I see it’s not mulithreaded so it’s not a solid choice. My PineBook Pro runs on the same AArch64 core as the RockPro SBC…

Feature Creep? Platform Creep!

I think platform creep is the feature creep being observed. Drivers for too many devices are bogging everybody down. WebAssembly can help processor architecture support but not driver support for every platform. Can we just target one cheap one first like an Atom SoC for now, then move up to more systems a few at a time? If too many devices are requested at once drivers will be the death of the project. I have an Atom notebook that came with Win7 Starter edition that I could dedicate to the cause. Writing drivers is boring without an automated way to generate them.

#6

AFAIK two platforms are targeted for R1: x86 64bit and 32bit

The other platforms are the side projects of a few individuals, not immediate goals for the Haiku project at large. Work on those platforms do benefit Haiku nonetheless, because it keeps the system spry and flexible for future developments and occasionally discovers bugs that haven’t surfaced with the target architectures.

6 Likes
#7

Those 2 overlapping architectures are instruction sets. I’m concerned that all the chips and cards that can be used with those architectures are still too many for the size of team that’s in place. Sharing drivers with other operating systems like the BSD network drivers is a great idea. Is there a way that that can be done for other peripherals? If so, who would you pool resources with?

I like the idea of skipping OpenGL and going straight to Vulkan (even though my Radeon HD6500 series graphics card is too old). WebGPU in the browser needs it and there are tools for running WebGL and OpenGL-ES on top of Vulkan as some have already observed. Using GL4ES, AmigaOS 4.1 got a lot of milage out of their OpenGL-ES 2 drivers on the desktop.

#8

My laptop is a Fujitsu U7311. As long as someone supports it (that will probably be me) I can run Haiku and that motivates me to keep Haiku working. Otherwise I will be forced to use Linux and then I have no reason to improve Haiku.

Unfortunately, other devs use other machines and we have to support all of these.

The plan for R1 is even more efficient than that: we have no plan for any 3D acceleration. Not needed for a first version, it can come later. One big problem out of the way!

1 Like
#9

After giving this some thought, keeping it simple is good. Chasing fast-moving Mesa code is no better than chasing fast-moving WebKit browser code. We’d then have two people tied up chasing fast-moving code bases trying to stay in sync instead of just one.

I don’t know what use I’ll be yet but maybe I can help with something yet. I’m not terribly fond of C++ because it does hidden things that C does out in the open. I’m beginning to think that excessive VTables and direct inheritance are an anti-pattern due to the dependence on pointer aliasing and double-indirection of function pointers to accomplish dynamic dispatch. That’s probably a discussion for another time (and a different thread if not a different forum).

#10

You forgot to add the word WebAssembly to this sentence. Maybe some more random terminology would also be helpful.

(sorry for being a dick, not meant personally)

#11

@bitigchi , I used it in my 10 year research project in this other thread describing the numerous projects my research had to be split up into to be practical. :wink: No offense taken.

#12

As I personally noted in my own experience, building Haiku from within Ubuntu was lightning fast (vastly faster than building Haiku from within Haiku). So I don’t see, necessarily, how using Linux would preclude improving Haiku. You improve Haiku for the sake of making your desired OS (Haiku) function better on your existing hardware. Sometimes you have to take an alternate route, to get to where you want. Or am I missing something? :thinking:

#13

I think I might have already touched on this in a previous post. However, in order to optimize drivers and supported hardware, we need to know how many people have what hardware. Many moons (hundreds of moons, perhaps? :rofl:) ago, I remember actually running Haiku on a Pentium II system. It wasn’t fast, but it ran. Does Haiku even boot/run on such old hardware anymore?

I got the impression that, as time went on, older hardware just got… forgotten about and was no longer supported. I think a certain “window” of functionality should be taken into consideration. How old is too old? How old is considered obsolete? What is the oldest hardware that Haiku currently will boot/run on?

At what point do we do what BeOS did and sacrifice some drivers/hardware, every so often, for the sake of efficiency (the change in BFS, I think it was, that obsoleted a previous version of BeOS… or was it a change in file format (something to do with ELF?))? It’s a tough row to hoe.

#14

If the OS does not work on my hardware and there is no plan to make it work on my hardware, it is not my desired OS anymore, it is just a toy to run in virtual machines and I have zero interest in that. So I will sigh, lose my interest, and move on to something else. Is that hard to understand?

Yes, if you have enough RAM

There is a minimum system requirements: a CPU with MMX support, and around 200MB of RAM. We verify this before each beta release.

We do get complaints that WebKit doesn’t run on CPUs without SSE2 support, which means there are some people still running Haiku on machines that old. So they are still supported. It is not a lot of effort since the work is already done, and keeping things working is a lot easier than getting new things working. There would be little to no gain in removing support for these old machines. Removing support is work, even if in the end it’s about deleting code, you have to figure out what code can be safely deleted, and there is a risk to break things while doing so.

#15

Interesting. I like Haiku for what it represents. Period. If it didn’t run on my current hardware, I’d find/buy hardware it did run on. I’ve never done that deliberately (Oh, wait… I did buy a graphics card (GeForce 3) for Haiku, hundreds of moons ago, because I’d read somewhere that Haiku had accelerated 3D support for nVidia drivers… come to find out, I was mistaken in some way or another), but the end result is the same. I like Haiku as an OS. Not just because it runs on my hardware. Haiku is still Haiku, and I like it, even if it doesn’t run on anything I own. I’m, likewise, not interested in running Haiku via emulation, but that’s why I’d find hardware to run it on…

Now, I gotta decide… if Haiku beta 4 runs completely on my Asus ROG Zephyrus G laptop (like it does on my Asus desktop build)… should I sell it for $450-$500… or keep it and use if for Haiku? Hmm. :thinking:

#16

“Most fascinating, Captain!” I was under the impression such ancient hardware had been left behind. But that was probably the nightlies breakage I was constantly running into that made me think that. We really do need to find a way to ship slightly more modern computers to people who can’t afford one. :grinning:

#17

Working with Mesa code base is much easier then WebKit because it is smaller and faster to build. I get working recent version of Mesa Llvmpipe, Lavapipe, RADV and Zink.

For WebKit even attempt to clone repo cause out of memory for me.

1 Like
#18

Why not provide RISC-V (and maybe ARM if become completed) support in R1?

2 Likes
#19

Targets can change, if the Haiku team deemed a platform to be sufficiently far developed and there appeared to be enough developers interested to keep it uptodate with the rest of the platforms, I suppose.

I was only pointing out the current status quo, when SamuraiCrow suspected “platform creep” when seeing all those different buildbots. That he dismissed, because he apparently actually meant supporting adidtional hardware (gfx,network…) running on those architectures.

#20

Assuming you were willing to work on WebKit… are you constrained by the ability to add more memory (motherboard won’t support it or not enough slots), or the money to buy more memory? How much RAM do you presently have? Do you know how much is needed?