To view parent comment, click here.
To read all comments associated with this story, please click here.
First of all, I would like to say that the geek in me sympathises a lot with what you say in your comment.
With that being said, how can people who see this as a problem prevent such things? Because, and I'm extrapolating here from the comments on this thread and my personal opinion, a lot of people seem to find the prospect of running non-native Haiku applications ontop of an interesting alternative Os like Haiku pretty attractive by itself. It may not be what you or even the core developers envisioned, but since the operating system is licensed under a permissive FLOSS license, people will start to do what they always have done if they have the possibility and means to do it: They will start to tinker and come up with crazy and sometimes even scary ideas.
The problems and inconsistencies you describe are imho not specific to Linux (although the Linux family of OSes is a good subject to study these effects) but are to varying extents part of the whole software development process. If a foo does not provide means to achieve bar and if bar is even remotely related to foo and important/interesting enough for a sufficiant number of participants in the ecosystem, either foo-bar will be developed or somebody will start/port an alternative to foo. The cathedral method tends to stop working once you open the bazaar.
Short of trying to keep the "official" Haiku distro as close to the "vision" as possible and ignoring everything else that happens in this space (which would likely increase the number of distros around, if Haiku by itself is viable enough to generate interest beyond the spheres of BeOS enthusiasts) or trying to make Haiku so cumbersome to work with that nobody even thinks about developing / porting applications for it (which would be a tad counterproductive and does not always work as expected, cf. Symbian :-) ), I'm afrait that I see no way to prevent a scenario where Haiku can be used in ways not desired by the enthusiasts.






Member since:
2005-10-17
Haiku has never been about being multiplatform or supporting multiple toolkits. This notion frontally contradicts a lot that Haiku has stood for from the very beginning: a compact, lean and mean system, consistent throughout by means of a single API that is both clean and complete (please, read the general FAQ on the Haiku website). This position is in clear contrast with the more complex landscape of mutiple toolkits, DEs, multiple layers of abstraction, etc. that, IMVHO, perpetuate the complexity of Linux on the desktop.
In this context, opening the gate to multiple toolkits would be taking the Linux road, and would signal the beginning of the end of Haiku how it was originally thought out to be. It will also most likely make the native API irrelevant, as nobody will care to use it in the end.
When/if that happens, Haiku is not compelling anymore, and it would become hard to find a valid reason why anyone would want to run in Haiku apps that already run, are more up-to-date and better supported than on Linux; such a scenario would only make Haiku another uninteresting "me too" OS.
Haiku can only become compelling if it has something fundamentally different and better to offer, and offering the very same user space stuff as other more mature platforms will not cut it. Only through native apps that take advantage and expose the unique qualities of the OS (multi-threadedness, extended attributes, data translators, media kit, etc. etc.) to the end user can take you there, even if it takes many more years (which it will).
I do understand the logic behind the desire for something like Qt, but I think it is being driven by an understandable but short-sighted impatience to have more apps in the short term than to stick to the project's original long term vision to develop Haiku into the unique platform that it was set out to be in the first place.