I am not sure if this should go in the Suggestion Box instead, but since I have both questions and suggestions I thought this is the better place to ask. I love Haiku, but this is not only a sentimental feeling; it is based on good design decisions of the original BeOS. Unfortunately time-wise I cannot contribute to Haiku currently as I would like (busy with a PhD), but I am thinking of writing a whole new GUI after the PhD which could actually position the next Haiku version as the best option for a personal computer.
Increasingly, as personal computers became more powerful, server-type features became part of the desktop operating systems more and more. This is certainly true for both Windows (since NT) and Linux (right from the start), but even for Apple (based on BSD). I really don't want a web server running on my laptop, to be honest (nor do I want a mobile interface), And do I really need or want a multi-user environment on my personal laptop?
So my first question is this: What were the design aims of the original BeOS? I assume that Haiku will want to aim at that and not just get stuck at version one (BeOS R5 compatibility). BeOS was marketed as "the multimedia OS". Multimedia has improved a lot since those times, especially on the hardware side. Do Haiku plan to support OpenGL? Do we want to support all the new hardware? Can we really call Haiku a BeOS successor as multimedia OS if we don't? If this is not the long-term aim of Haiku, what is? IMHO BeOS wanted to be the next Apple OS, meaning that even though it was marketed as the multimedia OS, it really wanted to be a full-on personal OS, a worthy option for Apple (and I still think it would have been a better choice than NEXT ;-) ). But this is a bit more than just a multimedia OS. Is this what we want Haiku to be?
Another thing to keep in mind, is that the desktop platform is becoming increasingly less important as mobile increases. However, for one thing it will remain the most important platform (at least for the foreseeable future and maybe forever): development. It means that as other OS's start to focus on mobile, server or the cloud, this could be an opportunity for Haiku to shine as a development platform. C++ is one of the few languages that is suitable both for low-level systems programming and for high-level application programming (another one that I like is Object Pascal = Delphi/Lazarus). Also, as a multimedia OS, Haiku could be the ideal platform for Game development, one aspect where both Linux and Mac have always trailed behind Windows.
In the long term, do we want Haiku to be a multi-user system? Multi-user systems make a lot of sense on a server where more than one user can be logged on simultaneously, but do we really want that for a home computer? The one area where having at least a normal user and a root user makes sense to me, is in terms of security and preventing malware from infecting my computer. From this perspective, some of the decisions with regards to the Package Manager and system directories being read-only, makes sense. However, then we have the issue of binary compatibility? IMHO, it should not be needed to change any BeOS application to get it running in Haiku... if it was, we loose all the advantage of binary compatibility. The whole aim of this compatibility is to have the full range of BeOS applications available for Haiku right from the start, instead of having to bother with application development for Haiku version 1.
Reading through the forums, I could not help but notice the growing frustration with the slow pace of development of Haiku, the current structure of Haiku Inc and the development process. I agree with previous posts that have suggested a Debian-like development cycle. Have an unstable version (the nightly builds) where things are experimental and expected to break from time to time. Then have a testing version where they are moved to once they have no obvious bugs and are fairly feature-complete. And then, at some stage freeze the testing version so that no more new stuff gets added, but only all the bugs in it are resolved in order to release a "stable" version (which might still be alpha or beta, since it will not be complete, but will at least be relatively bug-free).
But the second aspect to address, is the applications. In contrast to a typical Linux distro, and more like a typical Windows set-up, BeOS was an operating system only. The applications were installed by the user. I think Haiku should make a clear distinction between the operating system itself and the applications running on the OS. The aim for the first stable release of Haiku is that of an OS, full binary compatibility with BeOS, able to run all the original BeOS applications. But in contrast to Linux, the GUI and the kernel are not separate in Haiku, they are simply different modules, exposing a certain API to the user applications. The original BeOS applications should serve as the test cases for the testing and stable versions of Haiku OS. But new Haiku applications should also be developed or ported in order to draw more users and this should not be the concern of the core Haiku developers. These applications can already be aimed at the second stable version of Haiku, meaning there should already be a fairly clear idea of what this future Haiku version will look like. And this will mean that there should maybe already be developers working on additional features for Haiku that was not part of the original Be0S, but which will be part of the second stable Haiku version. This will be a known unstable version where things are expected to change and occasionally break.
I got the feeling that a lot of the application developer frustration with Haiku, was that changes specifically to the file directory structure, permissions and package manager, broke things that used to work. If there was a feature-stable testing version as well as an unstable version of Haiku, this would probably not have happened. The Package Manager, for example, would only have been able to enter the testing version once it was certain that no existing applications would be broken in the process. Then the testing version would be made available to the public to play with and test.From a user perspective, one of my frustrations (coming partly from a Linux background) is the fact that there was no full Haiku "distro" with all the most important application software already installed. I liked Senryu for this reason. If we want users to test our OS, we need to provide them with applications that they can use to test. Really, unless I am a kernel or module developer, an image of the OS without any applications is useless to me. I don't have the time or inclination to reinstall my applications from scratch every time.
The support for old, but useful, application software is one of the reasons for Windows'popularity (the other reason was their OEM licenses which effectively prevented PC's from coming pre-installed with BeOS or Linux). For this reason, I think it will be important for future Haiku versions to keep binary compatibility with BeOS. This is still better than having to keep compatibility with DOS or early Unix programs. The multi-arch options on Debian with both 32-bit and 64-bit programs running smoothly, shows that it is not too difficult to do. I think a similar approach should work for BeOS (32-bit and 64-bit as well as the gcc2 and gcc4 compiler alternatives). At a later stage, most apps could be ported to the newer ABI and the 32bit, gcc2 system could be run as a full-on emulation "skin", similar to WINE on Linux, for the few remaining legacy apps.
There are a number of things that BeOS got right and that I think any future Haiku should aim for:
- Fast boot-up time! Nothing else compares... As more and more server-type feature become part of the personal PC, the system just grows bigger and slower. While this is fine for a server that should stay online 24/7, this is not how most people use their personal laptops or what you really want on your own computer. The fact that Haiku tries to keep things simple, starting only a handful of services, have a modular design and with everything well-integrated into a single system, means that no OS I have tried can compare to it in terms of bootup or shutdown. We want to keep this speed advantage and should resist any feature creep that might endanger it; more features should not impact boot time or shutdown time
- Using an OOP language (C++) to write the system. How cool is that? This is something that can actually draw developers and should make things easier. Although I prefer Delphi to C++ simply for its compile speed, the fact that Haiku is written in C++ has always been a drawing card from a developers point of view IMHO.
- When I last used Haiku frequently, the whole debate on a Package Manager was just starting and as I remember it, opinions were pretty much divided 50/50. While I love my package manager in Linux, I liked it that for BeOS (and Haiku at that stage), I could just drag installation packages to the right folder and instantly have a running program. I hope that this can still work like this in addition to the Package Manager, at least for the first release of Haiku. (Behind the scenes the Package Manager can work all kinds of magic to make sure that the right libraries is installed and that the software can be removed cleanly later if required, but as a user, I don't want to be forced to use the package manager for installing programs, especially not since I might want to install programs not available from a central repository and doing it was so easy in BeOS). Making things easier for the user, even if it takes a bit more programming, should be a given. Could something like the nixOS system work on Haiku for this?
- I still remember the multiple 3D graphics on BeOS (turning teapots anyone?). If Haiku can keep the focus on its multimedia abilities, including support for modern graphics and sound cards, it can be the perfect gaming PC platform. The main problem is that it will need a big enough user base to draw game developers. But porting a game engine like Unity, or one of the open source alternatives that uses C++, should be a priority, I think. For a home computer this is simply non-negotiable.
- Stability because of the modular design and small size. When I first started using BeOS, Windows 95 was still the most common OS used on the desktop. BSOD was common. One of the reasons why BeOS was so small, fast and stable, was because they were in the unique position of being able to design and write an OS from scratch without needing to support legacy applications. By contrast, Windows still support DOS, 16bit, 32bit and 64bit programs today, making it bloated and prone to breakage.
- The BeFS. Journaling and a searchable DB build into the filesytem itself, long before journaling was common in any of the mainstream OS'es. Still a good design. ZFS seems to offer many of the same advantages. But once again, I am not sure if we want to have multiple options for a file system on Haiku. If we want an OS for tinkering and configuring, Linux should be the better choice,
- No issues with multi-user support for a personal computer that was only used by a single person. Keep it simple (KISS)... the only issue here might be future malware that should not be able to bork the whole system or install itself without the user's knowledge or needing any special programs to remove again from the computer. Maybe by having "hidden" user and root accounts and preventing any user program from changing system files.
- The familiar bash shell and POSIX compatibility was available for those special occasions when I still need/want a terminal. POSIX compatibility should also help with porting Linux software, especially those based on QT.
So far my ideas... Anything to add or areas of major disagreement?