Hello Friends,
I needed some education on the capabilities of Haiku. Response would be really appreciated.
Thank you.
Regards,
Ash
I’ll take a first shot at this and anyone else can join in and correct me or add more:
Programming+IDE Language Support?
Paladin or PE, but not true IDE support
Database Support - Esp Document Oriented ones…, CouchDB, MongoDB etc…
MySQL, PostGres, SQLite support. No CouchDB or MongoDB. Either of these could probably be ported…
Browser Support for HTML5? Read FireFox was listed. How about an inhouse browser?
Web+ doesn’t have it, not sure on the other webkit browsers
Scalability?
The microkernel will support 16 cores, and can be compiled to support an arbitrary larger number. But Haiku is intended as a personal OS and as such has not been tested under heavy loads.
Deployment on Netbooks/Mobiles?
No mobile development. Should work very well on netbooks with low resources, smaller cpus.
ARM/x86/x64
Limited experimental development for ARM and X86-64. E.G. the microkernel and parts of the other servers are running.
You keep using that word, I do not think it means what you think it means…
Please forgive me, of course I meant hybrid microkernel 
You either meant modular monolithic, or hybrid kernel - but certainly not microkernel.
Yeah, let me jump in here too and point to this wiki article http://en.wikipedia.org/wiki/L4_microkernel_family for a better idea of what a microkernel is. You know, instead of just pretending like I know.
[quote=AndrewZ]
The microkernel will support 16 cores, and can be compiled to support an arbitrary larger number. But Haiku is intended as a personal OS and as such has not been tested under heavy loads.[/quote]
B_MAX_CPU_COUNT is 8, not 16. So e.g. a Dell XPS 8500 desktop PC runs up to the Haiku limit right out of the box because hyperthreads count for this purpose and the Core i7 in that machine has 4 CPU cores each able to support two hyperthreads.
B_MAX_CPU_COUNT is rather unusual by modern standards because it’s visible to userspace. Structures exported directly from the BeOS / Haiku kernel to a user program use B_MAX_CPU_COUNT in their definition. This means that if you redefine B_MAX_CPU_COUNT (for example, to allow more CPU cores to be used) then your new version of Haiku is incompatible with (some) programs that were written on other copies of Haiku or BeOS and you can’t be sure which without having an expert examine them carefully.
In more modern systems the equivalent limit is not handled this way. Linux for example has CONFIG_NR_CPUS, but it’s irrelevant to userspace software. A program written for a system where CONFIG_NR_CPUS was 4 works just fine on a different system where CONFIG_NR_CPUS was set to 4096.
[quote=NoHaikuForMe][quote=AndrewZ]
The microkernel will support 16 cores, and can be compiled to support an arbitrary larger number. But Haiku is intended as a personal OS and as such has not been tested under heavy loads.[/quote]
I stand corrected.
You are really making a mountain out of a mole hill here with this hypothetical conditional. I have looked through numerous multi-threaded apps, mostly BeOS, and I have never seen B_MAX_CPU_COUNT referenced. If you know of any, please reference them.
[quote]In more modern systems the equivalent limit is not handled this way. Linux for example has CONFIG_NR_CPUS, but it’s irrelevant to userspace software. A program written for a system where CONFIG_NR_CPUS was 4 works just fine on a different system where CONFIG_NR_CPUS was set to 4096.[/quote] No arguments from me that this could be better configured. There was a time when you had to recompile your UNIX kernel when you added RAM to your system. There are certainly better ways to do things now.
You are really making a mountain out of a mole hill here with this hypothetical conditional. I have looked through numerous multi-threaded apps, mostly BeOS, and I have never seen B_MAX_CPU_COUNT referenced. If you know of any, please reference them.[/quote]
Anything that uses the OS.h system_info struct will likely fail binary compatibility if B_MAX_CPU_COUNT is changed without recompiling the software.
http://cgit.haiku-os.org/haiku/tree/headers/os/kernel/OS.h#n727
You can see there it uses B_MAX_CPU_COUNT to create an array in the struct, which will fundamentally change if the count is altered.
Thus B_MAX_CPU_COUNT must remain 8 for BeOS binary compatibility, as well as Haiku binary compatibility now as well.
That’s adominable! But as I said, I just don’t think there are that many apps, certainly not that many useful apps, that reference that struct. Why would they use it? Can you name any?
The Haiku project itself maintains Activity Monitor, Diskprobe, BSnow, Process Controller, ShowImage and Pulse which all use this structure along with a considerable number of command line utilities. Although there aren’t a tremendous number of “useful apps” for Haiku, obtaining the source code for them all and examining it just to disprove this claim seems disproportionate.
If these programs are run on a system with the “wrong” B_MAX_CPU_COUNT the system call they’re using gives an error, and most BeOS/ Haiku programs will ignore that and go on to access an unintialised buffer which is likely to cause a crash or bizarre malfunction.
The POSIX compatibility aspect of libroot encodes both the arbitrary maximum and the use of the structure, so any statically linked libroot in a ported Unix program would also be affected, but POSIX programs which dynamically link libroot should be fine.
Obviously if you recompile everything you don’t have to worry about the ABI, the BeOS philosophy was that the operating system and all applications should be replaced frequently and you should just stop worrying about compatibility.
[quote=NoHaikuForMe]
B_MAX_CPU_COUNT is 8, not 16. So e.g. a Dell XPS 8500 desktop PC runs up to the Haiku limit right out of the box because hyperthreads count for this purpose and the Core i7 in that machine has 4 CPU cores each able to support two hyperthreads.
B_MAX_CPU_COUNT is rather unusual by modern standards because it’s visible to userspace. Structures exported directly from the BeOS / Haiku kernel to a user program use B_MAX_CPU_COUNT in their definition. This means that if you redefine B_MAX_CPU_COUNT (for example, to allow more CPU cores to be used) then your new version of Haiku is incompatible with (some) programs that were written on other copies of Haiku or BeOS and you can’t be sure which without having an expert examine them carefully.
In more modern systems the equivalent limit is not handled this way. Linux for example has CONFIG_NR_CPUS, but it’s irrelevant to userspace software. A program written for a system where CONFIG_NR_CPUS was 4 works just fine on a different system where CONFIG_NR_CPUS was set to 4096.[/quote]
Can you point to example of a piece of software so poor written that is presently so written for HAIKU?
All the code (that includes my own that I personally wrote) that I have seen personally for Haiku usually creates the number of threads equal to the number of CPUs (B_MAX_CPU_COUNT) or in my case use a multiplier of two(2) to decide the number of threads created. Even if there is a fixed number of threads in a program why would that cause it to crash?
It would cause it just not to use all the power of the computer!
You seem to be suggesting a program with a fixed structure to track threads created but a variable thread creation system based of the CPU count. That does not make a lot of sense in HAIKU.
Are you sure you are not talking about BeOS that had a number of fixed structures in it’s base code?
Why? One does not access this structure directly to control threads, one uses the the thread functions to control them.
The count of CPUs and the number of threads running are handled at a higher level, only if you are writting kernel code should you care about this.
Please explain what I am doing wrong then since my code will run up to 500+ threads regardless if I have the computer set to 1,2,4 CPUs. And the only reason I don’t go higher while testing the code is the machine get sludgy at that point. What code needs this structure that userland programs will start to fail if you change the count.
Please, I really want to know as 12 CPUs (6 CPUs hyper-threaded) are already in the local stores, and I expect to see 16 CPUs (8 H-T) to show up by late next year when I need to buy my next machine.
The Haiku project itself maintains Activity Monitor, Diskprobe, BSnow, Process Controller, ShowImage and Pulse which all use this structure along with a considerable number of command line utilities. Although there aren’t a tremendous number of “useful apps” for Haiku, obtaining the source code for them all and examining it just to disprove this claim seems disproportionate.
If these programs are run on a system with the “wrong” B_MAX_CPU_COUNT the system call they’re using gives an error, and most BeOS/ Haiku programs will ignore that and go on to access an unintialised buffer which is likely to cause a crash or bizarre malfunction.
The POSIX compatibility aspect of libroot encodes both the arbitrary maximum and the use of the structure, so any statically linked libroot in a ported Unix program would also be affected, but POSIX programs which dynamically link libroot should be fine.
Obviously if you recompile everything you don’t have to worry about the ABI, the BeOS philosophy was that the operating system and all applications should be replaced frequently and you should just stop worrying about compatibility.[/quote]
Thank you, I will be doing some reading and testing on this myself.
But Bsnow? Why does need such, for what it does one thread should be all you need.
Again DiskProbe? Did I miss some extra function that needs to see the number of CPUs? Why?
ShowImage is key for as I need that code as the base of a program I am writing, I will be looking into it’s code carefully.
Thanks again for the pointers.
I only have time for a brief example, there is plenty of other stuff that needs doing
So, take a look at the ImageCache class in ShowImage. This class defines a variable fMaxThreadCount which controls how many threads may be used by image loader workers. To decide a value for the variable ShowImage proceeds by creating a structure on the stack and calling get_system_info, a macro which eventually expands to the Haiku system call _get_system_info()
If B_MAX_CPU_COUNT is changed, the structure size doesn’t match and this results in _get_system_info() returning immediately with an error code. ImageCache doesn’t check, it presumes that the structure is now valid, and it initialises fMaxThreadCount based on the (garbage) contents of the structure. This can mean ShowImage begins trying to use thousands or even millions of threads on a modest home PC.
This problem is inherited from BeOS. Because Haiku has yet to define its own APIs to replace those from BeOS this is a distinction without a difference.
Haiku has already some good technology under the hood, but it’s still a lot missing. There is still a lot to be improved, and there is not really a good reason, to try to make it look better than it actually is. If somebody takes the time to point out the weaknesses, we should thank that person for taking the time, because it’s more productive/important than the praising words (even if they might be true). The weak points need to be shown up, and also as often as possible, if we want them to be become solved in the near future. You win nothing if somebody tells you how great you are, and what stuff you already know to do, but you win a lot more if somebody tries to criticize and say where you can improve, and where your weak points might be.
[quote=NoHaikuForMe][quote=Earl Colby Pottinger]
Can you point to example of a piece of software so poor written that is presently so written for HAIKU?
[/quote]
I only have time for a brief example, there is plenty of other stuff that needs doing
So, take a look at the ImageCache class in ShowImage. This class defines a variable fMaxThreadCount which controls how many threads may be used by image loader workers. To decide a value for the variable ShowImage proceeds by creating a structure on the stack and calling get_system_info, a macro which eventually expands to the Haiku system call _get_system_info()
If B_MAX_CPU_COUNT is changed, the structure size doesn’t match and this results in _get_system_info() returning immediately with an error code. ImageCache doesn’t check, it presumes that the structure is now valid, and it initialises fMaxThreadCount based on the (garbage) contents of the structure. This can mean ShowImage begins trying to use thousands or even millions of threads on a modest home PC.
This problem is inherited from BeOS. Because Haiku has yet to define its own APIs to replace those from BeOS this is a distinction without a difference.[/quote]
Thank you. I may seem harsh at times but lately (the last year or so) you have posted some very useful info. So keep posting, and I will keep reading.
Hello minaalashokvijaya!
I see you’ve been a member for one week. I think you’ll enjoy Haiku. I hope you do. Like all forums, threads like this one can get to the point where they have seguayed into vaguely related subjects that may not be what the OP was looking for.
Haiku is probably one of the best pieces of alpha software that I have ever used in my life. I’m making a comparison that includes Microsoft.
Now, Haiku doesn’t do everything yet, but I use it for about 60 percent of my computer related activities, even though I’ve read in the release notes that I should consider that Haiku has an “alpha” status, and that there could be possible data loss. In terms of my usage, Haiku is currently serving as an internet interface. I do much of my internet with Haiku. Two of the three machines in this room run Haiku. I use Webpositive, which still has some issues, but Mr. Leavengood is making great strides with it, and is handling the bugs that I see in bugtrak (dev.haiku-os.org). There are sites that do not render properly, but I’m living with it. The rest of my activities remain delegated to FreeBSD. I foresee a time when I won’t need to use FreeBSD anymore (that project has developed some issues, in my opinion).
Webpositive does currently do a subset of HTML5. You can go to one of the HTML5 test sites to verify this. It almost never crashes. In fact, Haiku itself rarely crashes for me, and I typically use it at least three hours per day. I experience a crash maybe every few days or a week. Mileage may vary, depending upon what you’re trying to do.
I think you should follow the release note’s advice, and not use Haiku for production purposes. Yet, I think you will be surprised at the stability of something called “alpha” software. IMHO, these devs would shame microsoft. Take a look at some Haiku code. Then, take a look at some of Microsoft’s public code (You can get some of that in the platform SDKs and the Device Driver SDKs). I think you will see what I mean. I think the extensive use of C++ is one reason that Haiku code looks so clean.
I think that Haiku is good enough that the apps will come someday. For one thing, it has very commercial-friendly licensing. So, it’s not quite there yet - but it’s getting there with the speed that’s necessary and appropriate for the maintenance of the quality level.
One of the computers that I use with Haiku is an MSI netbook (1G Ram, 1.5G dual core atom cpu).
The dedicated Haiku devs are real nit-pickers … exactly what you want in developers. Maybe that’s why they sometimes take the thread a little off-course.
[quote=NoHaikuForMe][quote=Earl Colby Pottinger]
Can you point to example of a piece of software so poor written that is presently so written for HAIKU?
[/quote]
I only have time for a brief example, there is plenty of other stuff that needs doing
So, take a look at the ImageCache class in ShowImage. This class defines a variable fMaxThreadCount which controls how many threads may be used by image loader workers. To decide a value for the variable ShowImage proceeds by creating a structure on the stack and calling get_system_info, a macro which eventually expands to the Haiku system call _get_system_info()
If B_MAX_CPU_COUNT is changed, the structure size doesn’t match and this results in _get_system_info() returning immediately with an error code. ImageCache doesn’t check, it presumes that the structure is now valid, and it initialises fMaxThreadCount based on the (garbage) contents of the structure. This can mean ShowImage begins trying to use thousands or even millions of threads on a modest home PC.
This problem is inherited from BeOS. Because Haiku has yet to define its own APIs to replace those from BeOS this is a distinction without a difference.[/quote]
Okay, I took a look the programs and the struct to see the cause of the problem.
First, I have a major headache from banging my head against the wall once I realize the mistake made in BeOS! If the CPU-INFO array was at the end of the struct there would be no problem as all the other variables were in effect fixed in size.
Then there is the programs:
Bsnow! Really? Base the timing of the program by using the CPU speed found in this structure? Not only does it not needed to have multiple threads the clock rate of a CPU is not a good basis to calculating speed of your display. If instead they used the sleep_until() or even just sleep() functions they would have gotten the same timing control. Bad programmer - very bad programmer.
DiskProbe! Yep a victim of the bad structure since it uses this struct to get how much memory is available.
ShowImage hurts. Same problem as Diskprobe, I see why you say this is a problem for old Haiku/BeOS programs. Problem is how to break the log-jam.
I see three diffirent solutions, and all have their bad points. But to get out of this log-jam something has to break or a bad kludge will need to be added.
All the choices leave a bad taste in my mouth but for cleanness of code it looks like this struct must be re-ordered even changed to replace the CPU array with a pointer to an array else in memory so it can be any size needed.
What a mess because someone did not think users would have more than 8 CPUs! Ha, Intel already has a design for 256 CPUs on a chip and you can already buy off-the-shelf server designs with 16 or more CPUs (especially if you include hyper-threaded designs).
Again, what a mess!
Agreed, some of those apps are poorly coded and that system_info struct makes me want to barf But my point (and thanks to NoHaiku for listing apps) is that there are several things to be done to add support for more CPUs in Haiku:
There is no pressing need for this in the short term because Haiku is intended as a personal OS, as there aren’t many apps that really need all those CPUs. But still, it would be nice to have.
In the short term, anyone can increase the MAX CPU, recompile Haiku and do some testing. A Mac Pro would be a great test workstation. It is mostly compatible with Haiku and has many cores.