Haiku longterm roadmap - some ideas and clarity

koki was already asking the same questions back in 2004.

“The goal for the initial 1.0 realease of Haiku is to create in principle an operating system that is source- and binary-compatible with BeOS R5, but without some of its limitations. When compared to BeOS 5.0, Haiku 1.0 will have a faster and more robust network stack, will overcome BeOS 1GB memory limitation, and will include JAVA (add here any other improvement that you know/think/expect will make it into Haiku R1). Further improvements to Haiku will follow after R1 is completed.”

Where is the “Our Goals” page today?

It would be better to start small with Haiku 1.0, by releasing it as a repair / maintenance / utility OS. Include all the utility apps for useful working on drives, filesystems, etc:

  • CD/DVD writer
  • USB image writer
  • partitioning tools
  • formatting tools
  • disc drive tools
  • USB flash drive tools
  • system info tools
  • text editors

Quick booting maintenance CDs are always handy. There doesn’t need to be any further apps to download or install. And while people are trying it out, the devs could then work on the bigger tasks of office suites, DAWs, browsers, 3D graphics, etc to build the OS up over time.

[quote=pistooli][quote=korli]Seems to me you have plenty of time to think. Too bad you haven’t any to contribute :slight_smile:

Bye[/quote]

He just did contribute well enough…[/quote]

I think he drops suggestions in the box very well indeed.

i really couldn’t say, nor could i point you to similar for windows, osx or linux.

Hi, here is my vision as a developer of Haiku: it IS already ready for my use as a desktop OS. Not #4, but #1 on my system, far above either Linux and Windows (and I don’t run Mac OS X at all). However, there is still a lot of work to do before I would consider it for installation on friend’s or family machines. I do my best to make that happen, but also to improve my own work flows with the OS.

My work includes improving the web browsers (I worked on Web+ and on NetSurf), and I hope we will get Google Docs running to help with the "office suite" situation. My work includes writing drivers for the hardware I have at hand, fixing the bugs that annoy me most, and also trying to help others become part of the Haiku community and contribute in their own ways, by writing applications or fixing/improving the OS.

The development team is not necessarily having a single goal. Some people are interested in hacking the kernel and experimenting with operating system design, for personal learning purposes. Some are running and using Haiku, some prefer to run Linux, some have to run Linux because the apps required for their work flow is not available in Haiku yet (Eclipse IDE, or whatever). Some are here just for the nostalgia or for bringing in some fun like the 68000 port. There is not a single vision of "the development team", as far as I can see. We tend to agree when there are specific technical decisions to be made.

But now it’s better. You can download a smaller system (600mb) install only parts you are intrested in (probably not more than 200 mb) and make your own installer usb with things you are intrested in and like to have.

If more things would be preinstall you will have things you probably don’t want.

and if you boot on the stick you can update all packages and system in one go.

Spinach

I’m not asking for a brand new, Haiku native office suite. That WOULD be too much to ask, I agree, but havng a native port of LO or OOO is not only a reasonable request/desire it is realistically expected of a 15 year old desktop orientated OS. LO has many dependencies and last time I checked over half were already ported to Haiku so we are most of the way there in that respect.

I love Haiku and I think its very impressive considering the small team behind it. I was going to create a video about it recently but I didn’t bother because of the lack of native, usable, offline (or online) office software. I couldn’t bring myself to immortalize in video form me having to come to the conclusion that I cannot seriously recommend Haiku to anyone who isn’t interested in OS dev because of this huge missing app segment. It’s a sad fact but most computer users need to open Word and Excel files. They’re as much a part of the computing landscsape as PDF, JPG and PNG files, unfortunately.

I’m aware Haiku has Gallium but only software rendering. Without hardware support its not much use sadly. Even if that does catch up to the level of the Linux FLOSS drivers, its still way behind Windows and the closed source Linux graphics driver performance levels. Unless Steam for Linux takes off in the next year or two, I’m concerned about the future of Linux gaming, nevermind Haiku.

If you are using Haiku and its not primarily because you’re a BeOS / retro computing fan or a hobbyist OS/systems software dev then you will be in the minority. I want Haiku to succeed, that’s why I’m writing this but I cannot think of a single good reason to recommend it to people who are not in those categories yet sadly. Telling them they cannot open most of their documents is too much.

As others have pointed out already, a re-install shouldn’t really be needed anymore, since we can update Haiku (and all installed apps) for some time now. You can also opt to install to the home hierarchy, which is safe from a reinstall (currently only when using the CLI pkgman, but probably the GUI HaikuDepot will get that option as well. Also, the Installer might be changed not to overwrite non-system packages when installing over an existing Haiku. Though with an actual re-install you might prefer to have a clean slate, system-wise).

Besides, since the HPKG packages aren’t unpacked into the filessystem as it’s common for other OS, creating backups is very easy by copying single files onto e.g. a USB stick or your NAS.
If you prefer not to install a possibly outdated package from your backup, you may want to consider creating a shell script to have pkgman download/install the current version of your personal collection of applications.

Regards,
Humdinger

So it looks to me that currently the biggest problem with Haiku is not so much the lack of OS developers, (although things like hardware 3D acceleration would need to be addressed in some way, at least for r2), but the need for more application developers? This might be related to my first post about the idea I got from some application developers that the introduction of the package manager made their jobs more difficult by breaking their previous work (and maybe breaking legacy BeOS apps)? Will it be a solution to provide an original BeoOS R5 virtualbox image for application developers to develop for Haiku r1 (I am not sure how legal this would be)? This will then be the current "stable" branch of "Haiku" until it gets replaced by the real stable Haiku r1. In this way the Haiku developers can be sure that their changes to the package manager or file system will never break an application? And application developers can be sure that their application will run on Haiku r1. And then have the unstable (future r2) nightly build version of Haiku for those developers who want some of the more modern features, but with the understanding that things might break? And have the testing branch of Haiku where most bugs have been sorted out and where those same applications that have been tested to work on BeOS, can be used to test Haiku (future r1) for feature-completeness and bugs.

It sounds to me as if the current Haiku package management is working well; I have not been able to test it yet, because of the EFI issue. But I also got the feeling that there were/are a bunch of application programmers that are disgruntled with it (because it breaks their previous applications)? Since we need to get more application programmers, it should be a priority, maybe even more than hardware acceleration (for r2) and support for (all) modern graphics, to provide application programmers with an inviting platform. A nice IDE, good API documentation, a stable platform as far as possible, example code for using the OS API's etc. This should not be an IDE/build platform aimed primarily at the Haiku kernel coders, but mostly at making things easy for application developers (i.e. something like Visual Studio, C++ Builder, or Delphi/Lazarus, but adapted for the Haiku environment).

I remember that at one stage there was talk of porting Lazarus and fpc for Haiku, but I think that project died? Lazarus do have QT support already, so it will probably be at the fpc level that things will need to be changed. But for all I know the current Haiku development tools are already all good enough. My question then is how to draw more developers? Once you have interested developers, we will see more interesting applications (including a nice office suite), which in turn will draw more users.

There are way too many question marks in your assertions…

I don’t think that idea that came to you is grounded in reality. There were very few application developers before the package management was included, and there aren’t many now. It’s not that PM has scared app developers away, on the contrary, many see the advantages in handling updates or dependiencies, for example. But as PulkoMandy keeps saying, list all those supposedly PM-broken BeOS apps and people can work on fixing the issues, if possible.

You could very well test the OS so you don’t have to make so many guesses by running it in a virtual machine.

Regards
Humdinger

Maybe a pinned news item on the homepage outlining “the state of package management” would be helpful overall. How it works, where non-packaged files need to go, and maybe a check list of what do do if an application doesn’t seem to work correctly under PM.

Could be useful until the next release is out the door.

T. J.

[quote=humdinger]
You could very well test the OS so you don’t have to make so many guesses by running it in a virtual machine.[/quote]

You are right. It has been a while since I last used Haiku, so let me first try it again... :-) I'll get back later with a new perspective, I think. Do you know if anybody is currently working on getting EFI working in Haiku? Having to install inside a virtual machine removes one of the great advantages of Haiku, the fast boot times (although it sounds like I should maybe install a basic Arch Linux setup with only a VM inside for Haiku if I want fast boot times). :-)

When talking about a game engine, I mentioned Unity (since it is well-known and apparently good). It does have the major drawback of needing C# / .Net / Mono. Another nice-looking option, which actually seems as if it will be a nice fit with Haiku, is Panda3D (it uses C++ and Python). I would be interesting to see if it works with galium3d.

How feasible is this? Are there currently people looking at putting together an inexpensive "Haiku-box"? :-) In terms of 3D acceleration and drivers, how much easier will this make things for the Haiku kernel developers if we aim for a specific "Haiku compatible" laptop/Raspberry Pi/Intel Compute Stick and focus on making sure that everything works perfectly on (at least) that one specific platform?

This would be another option. But the big issue I see with a maintenance CD compared to the first option above, is that you really want good hardware support... it should work with (almost) any hardware out-of-the box (else, how is it going to be useful for fixing things?). E.g. the hardware support of Knoppix is one of its major attraction points and one of the reasons why I used it as my first Linux distro even though it is not really meant primarily as an installed Linux system. On the other hand, if the main Haiku kernel developers would decide that this is their first target (instead of a full BeOS R5 compatible r1), it might loosen their hands a bit to focus on these few things only. And once your hardware drivers etc. is sorted out, it will give you a very nice and stable base for building the rest of the OS and user applications. So in the long term, it could speed things up to r2, I think. This might be the best option if most Haiku developers are currently kernel hackers, wanting to work on the OS itself, rather than application development... i.e. if we have more OS developers than application developers.

The third option, and the one I think Haiku is currently aiming for, is what danboid mentioned: [quote=danboid]

For myself and many others, I absolutely MUST have:

  • * A stable, modern browser
  • * A terminal
  • * A decent, offline productivity suite (Libreoffice)

[/quote] From a Haiku kernel perspective, I think this option will probably be able to get away with a little less hardware support than option 2 (i.e. might not support all hardware as well as one would expect from a live recovery disk, no need to support "foreign" file systems etc.). However, it would still need to support most common hardware. But it will also not need to have full compatibility with all the legacy BeOS applications before it can be released as a usable basic home system. Here the people who would need to step up to the plate would really be the application developers, rather than the OS developers. In other words, if we have more able and willing application developers, rather than kernel hackers, this could be the best option.

Fourth option: only release a "stable" Haiku once full binary compatiblity with BeOS has been reached. I don't think this is such a good idea. I think there should be usable "testing" versions of BeOS beforehand, both to get more application programmers and to keep user interest.

What do you think?

The user guide describes the basics of HPKGs and how to use the non-packaged folders. The package management is working and testable in the nightly images. Apps failing under PM that worked before and suggestions for concrete improvements can be submitted as bug/enhancement to the bugtracker, as with any area of the OS.
I don’t think there are that many problems with PM to warrant a pinned news item.

Jessica used to work on that, but I haven’t followed its progress closely.

Regards,
Humdinger

that’s been tried multiple times and just isn’t happening anytime soon. more than likely our office suite will be google docs, which reads all the ms office filetypes, is more stable than LO/OOo (they’re really not that good among office suites) and is fast growing in popularity.

they are literally the same drivers. when hardware support happens at haiku’s end, haiku and linux will be on equal footing. till then – go ahead and try anything graphics intensive in haiku, it works pretty well. games on linux are still not a thing despite valve’s support – valve can port their storefront all they like, it’s still up to devs and publishers to port their games to linux, which is both difficult and unrewarding since the linux audience is still tiny. haiku doesn’t need and can’t have the gameplaying audience. linux and osx are doing fine without that, also. there’s no need. what is here is an environment conducive to making those games, or at least their assets. which is fine, osx has been that, solaris had been that at its height, it’s fine. what’s not fine is pointing at the still buggy, still largely unsupported (i mean, you can play doom 3 and tux racer, but that’s it) linux distributions as a goal for the point at which we can say haiku is a gaming machine. and haiku has games! people have ported and made games and emulators for haiku. try them, this isn’t theory, you can go run them right now.

and you’re basing this assumption off of what? the absence of things you feel must be present in order to attract an audience? assuring me my voice and needs don’t matter when i tell you i exist is a hell of a way to get more of an audience for this thing you’re supposed to love, also. i’m not an office professional, i’m a media professional, i don’t need an office suite but a production suite – that’s a lot closer to existing on haiku than anything, it doesn’t require hardware acceleration and can’t use it anyway even if you had it (for instance, ffmpeg doesn’t use hardware acceleration and neither does apple compressor – i’ve used both to render video for cinema screenings, getting better performance out of either relies on processor cores, ram and file i/o only), so the current opengl software rendering solution is fine. the stated critical needs are exaggerations with no basis in an actual workflow (and again, the chances of seeing game industry support are nil, treating that as a requirement for completion of this os is ridiculous).

But now it’s better.[/quote]
you are literally ignoring something this person is saying they need, it’s not better, they’ve said why it’s not better.

[quote=syd]It would be better to start small with Haiku 1.0, by releasing it as a repair / maintenance / utility OS. Include all the utility apps for useful working on drives, filesystems, etc:

  • CD/DVD writer
  • USB image writer
  • partitioning tools
  • formatting tools
  • disc drive tools
  • USB flash drive tools
  • system info tools
  • text editors

Quick booting maintenance CDs are always handy. There doesn’t need to be any further apps to download or install. And while people are trying it out, the devs could then work on the bigger tasks of office suites, DAWs, browsers, 3D graphics, etc to build the OS up over time.[/quote]
there are much better and lighter repair disks than haiku ever can be. that’s a whole big specialized industry.

[quote=spinach]haiku doesn’t need and can’t have the gameplaying audience. linux and osx are doing fine without that, also. there’s no need. what is here is an environment conducive to making those games, or at least their assets. which is fine, osx has been that, solaris had been that at its height, it’s fine. what’s not fine is pointing at the still buggy, still largely unsupported (i mean, you can play doom 3 and tux racer, but that’s it) linux distributions as a goal for the point at which we can say haiku is a gaming machine. and haiku has games! people have ported and made games and emulators for haiku. try them, this isn’t theory, you can go run them right now.

i’m not an office professional, i’m a media professional, i don’t need an office suite but a production suite – that’s a lot closer to existing on haiku than anything, it doesn’t require hardware acceleration and can’t use it anyway even if you had it (for instance, ffmpeg doesn’t use hardware acceleration and neither does apple compressor – i’ve used both to render video for cinema screenings, getting better performance out of either relies on processor cores, ram and file i/o only), so the current opengl software rendering solution is fine. the stated critical needs are exaggerations with no basis in an actual workflow (and again, the chances of seeing game industry support are nil, treating that as a requirement for completion of this os is ridiculous).[/quote]

Personally, I do not think game industry support is a requirement for completion of this OS. However, if it should become the home OS of the future (which I hope it will become) and for which its design is better suited than any of the other OS options IMHO, then the ability to write and play games become important. Yes I remember playing Doom (or was it quake) a long time ago, and it was OK. I am not sure if anything new has happened since then on the gaming side, however. Even though it is not a requirement, I do think is could become a strength of Haiku (good multimedia tools and a good underlying multimedia platform should also make using that platform in games easier, not so?). But even then, it would be something I expect from r2 and onward, not in r1. But that shouldn't stop anybody interested in this to get 3D hardware acceleration working in Haiku?

My point, and one of the reasons I started this thread, is that we, both current users and programmers, should start thinking about what we want for Haiku after r1. This could mean that new developers (if we can get them) can start working on those future features that are most important. And if we could have a Debian-like release cycle, this will also help to not get feature creep in Haiku r1. Some (new) developers can start working on these "unstable" future features, without impacting the release date of Haiku r1 by trying to integrate these new features into r1. It will also mean that when r1 finally gets released, we will not suddenly be directionless, but already know what the next things should be to work on.

I hope this makes sense.

More than a decade ago Haiku (then OpenBeOS) had the “Glass Elevator” to discuss this hypothetical R2 work. A wise person learns from the mistakes of others. A fool does not learn even from their own mistakes.

NHFM,

Tell me more about this "Glass Elevator" please... what mistakes are you talking about? And maybe just as an aside: your name tells me that you are not a Haiku fan. Why not? In this discussion so far, what are your major concerns that have not been addressed (except the obvious one of Haiku probably not having enough developers at the moment to speed things up)? Did you like BeOS? The fact that you still hang around, tells me that something about Haiku still interests you (e.g. I don't hang around any of the AmigaOS/AROS forums or sites, since I really have no interest). What is your interest in Haiku? Are you a programmer?

I’m still hoping for eventual 3d driver support too… hopefully kallisti5’s radeon modesetting driver eventually grow into a full 3d driver. Especially considering mesa3d is besting the proprietary driver im many tests on Linux now for last generation cards.

The rest of Haiku is pretty ok at this point IMO.