Look to the Future

a degree of modularity never seen in any of the big three. right now, the media kit offers functionality available to other operating systems only through extensive hacks that threaten to destabilize the entire system (i.e. reliably streaming video from one app to another, through filters etc) out of the box, allowing multimedia professionals an incredible amount of control over the design of their toolchains without the need to write a single line of code. because of haiku's modularity, apps can be built lighter and filetype compatibility can be added on the fly and systemwide. there's nothing remotely like it in the big three operating systems.

yes, the idea sounds good , sadly there are enough devs who consider haiku perfect :-)
Here we can quote axeld "just over my dead body". :)

we can just hope that the first beta comes out soon. And the R1 release too.

But what will happen after R1? I have no idea, since some have are more conservative view, and think that "touch" is evil[exagerated].

With haiku itself I'm happy in fact, just the UI is far from great, and the api doesn't allow you so far to make for example non-rectangular windows, and transparent/translucent windows.

When I see the plans and progress of ubuntu touch, I start to get the impression, that haiku is not getting closer to linux. Valve is saying that linux is the gaming platform of the future, and they could be right, at least it has a chance, and money is invested in this direction.

Haiku is a direct, native reimplementation, there are no "layers and layers of backwards compatibility".

Haiku runs fine on multicore, 64-bit port is available. GPUs is mostly a driver problem, modern GPUs are extremely complicated and often highly proprietary devices.

So you choose Legacy OS, okay.

We aren't going to drop gcc2. Here are some reasons for this.

- We really want to keep that BeOS compatibility in R1. This allows us to test our code and make sure it behaves the same as R1 did. We're not doing a bug-for-bug clone, but a feature-for-feature one. This is the only goal and purpose of Haiku until R1 gets released, and it allows to keep the developers somewhat focused.

- It isn't making any part of the OS stay in the past. We have implemented the layout kit, we are running the very latest version of WebKit which uses C++11, and people can develop applications using gcc4 very easily, it's just a matter of using gcc-x86 instead of gcc in the command lines.

- The ARM, PPC and x86_64 ports use only gcc4 anyway. I'd say ARM and x86_64 are clearly the future anyway, so if you want to look towards the future, just use the x86_64 version of Haiku and forget about this gcc2 mess

- The "hybrid" system is reusable. Think of gcc2/4 hybrids as a testing area for this. We set up everything to get that working in all cases, and now we can reuse it without too much work to provide the forward compatiility etween releases. Whatever changes we make to Haiku, the apps released for R1 will run on R2, apps released on R2 will run on R3, and so on. This will require the same hybrid system. It also means we have done a good part of the work for 32/64 hybrids. This is not yet possible, but already having an hybrid environment makes it easier to do.

- It isn't a problem as big as most people seem to think. You can use gcc4 when you need to, we do this inside the system (WebKit is an example), and in the applications as well (many of them are gcc4-only). With the new package system we can even keep old versions of software on the gcc2 side and new versions on the gcc4 side. This has a very low maintenance cost.

On the move to touch interfaces now: as far as I can see, everyone agrees that an interface can't target both desktop computers and touch devices at the same time. This is why we have iOS and MacOS X, Android and Chrome-OS, and this is why Windows 8 has two interfaces in the same OS for a very weird user experience.

Now, Haiku has a goal which is to replace BeOS on desktop computers, and make new things in the way BeOS could have done them. In my mind, this does not include a move to touch devices (Be already tried and failed that, remember the "focus shift"). I'm not saying touch interfaces are evil, just that they aren't what we are targetting. Now, if someone was to take some components and design from Haiku to build a touch-oriented system, I think it's possible to get very good results. But would that be Haiku ? Certainly not. Would it run the same apps ? Maybe, but they would still be unusable on touch devices and probably need some major UI rework. So, I think something like iOS/Mac OS X (they share a lot of code, but not the user interface) makes more sense.

Now, I'm not interested in this, because I don't even have a touch-oriented device here. So, I'm focusing on getting Haiku running on my computer and doing useful things with that. If someone wants to build a touch interface for Haiku, well, maybe we'll accept the patches. But we don't want this to replace the current UI.

As for looking into the future: R1 is getting close now. Work has already started towards making Haiku better than BeOS in many ways. Look at the Wifi support, look at the WebKit port, at the Layout Kit and the work from the university of Auckland (they are doing great research on the future of user interfaces, and their playground is Haiku). There are also many less-visible changes like the work Pawel is currently doing on the scheduler and things he did before such as DEP and ASLR (essential to bringing some security against malware/attacks). There are also the ARM and x86_64 port, the package manager, and many, many other things.

There is a high amount of uncertainity as to what Haiku will become after R1. The "Glass Elevator" project has few activity, and I think there will be a "what now?" feeling after we launch R1. The current devs each have their own idea of what the future of Haiku should be, ranging from "more of the same" to "let's use Qt as the main API". I can't say who will won, or maybe no one will and we will see multiple forks of Haiku, each doing different things.

There's not a lot of point developing a touch-based UI anyway. Most touch-based devices are much more heavily locked-down than PC's, and IMHO the return on investment is pitiful. And anyway, desktop are not going to disappear overnight, people need a platform that can actually be productive.

And as PulkoMandy said, there's no real issue with GCC2 anyway, when all builds other than x86-32 use GCC4 anyway, and even the supported x86-32 build is a GCC2/4 hybrid. GCC2 is there for BeOS compatibility. It doesn't affect stability, app compatibility, or the ability to port software. Unless you use a GCC2 only build, in which case you're an idiot.

these are priorities. already we've got people running haiku on 8-thread quadcore processors (haiku reports eight cores, even), and more work is being done on the scheduler. haiku is now supported by gallium3D, you can track its progress.

all that progress linked above happened without dumping gcc2 (also alpha4 is a hybrid gcc2/4 environment)

except without interapp video streaming (still in the works, last i checked), there's a lot of duplication of effort and when working on a video project in multiple apps the same data then has to be duplicated at several points in RAM (their RAM compression seems neat though) and project requirements begin to balloon as a result. haiku's media kit allows multiple apps to access the same buffer, the absence of duplication allowing for less transcoding and less need of proxy files. look at the way, say, davinci resolve uses nodes internally -- it is entirely possible, in haiku, to build native apps which perform as nodes do in resolve (also note, replicants allow for one to build a gui very similar to that shown in this demo, again from separate apps). the same can be done for audio. that's huge.

well, gcc2 isn't the only supported compiler -- gcc4 is, as well (and as pulko_mandy noted, gcc4 is the only option in the x86_64 version).

Simplicity is good, but I think the most important thing is it's fun!
I like Haiku because of the app-icons, for example, it make the OS look a bit less serious and more friendly or something. This is what really defines the style of a system and make it not just another OS, but something special.

Also, the API makes it easy (for me at least) to build complex applications in not too much time. It isn't perfect (but what is?), it's maybe a bit outdated, but all these things can be solved and improved - with or without gcc2. The important part there is keeping the "spirit" of the API and getting the new stuff to blend in. I think the Locale Kit and Layout Kit, and now the Service Kit show this is possible. Now we're waiting for new contributions going that way :)

feature complete would be beta. this os is still in alpha state. work is still in progress and it's also being carried out largely by volunteers -- not the company that sold all rights to palm for $11 million or that got a $23+ settlement out of microsoft, but individuals working in their spare time with zero startup funding (note: it took three years of fulltime work before beos reached its first release, and another eight before danos was ever a thing -- that's eleven years with fulltime staff). not to mention this is software being released completely free of charge and which supports a huge variety of hardware. you're completely free to help in any way you like, regardless of skill, so if there's anything you want that is missing, put in some work, put up cash on a bounty or wait. there is nothing even remotely okay with treating a group of volunteers this way (some of whom, it's worth noting, happen to have written those apps you enjoyed so much in beos in the first place).

r1beta, by definition

here's the roadmap. if there's anything you feel is missing, you can create a ticket for it.

i was just answering your question of when r1 will be feature complete and pointing out that if there's anything you feel is absolutely necessary for a feature-complete release, you can write a ticket and someone will take care of it. or, you may find that certain functionality you want either already exists and has yet to merge into the main branch or work is already in progress addressing it. it's a pretty cool setup.

nor do i; i'm still pretty new and learning. i've built systems before, but that's a more a matter of putting existing things together. there's room for everyone to contribute, and i don't just mean monetarily -- submitting bug reports and pointing out hardware that could use some support really does go a long way: whatever problems any of us encounter individually, someone else is bout to encounter along the way. you've been testing video formats -- that's definitely something, and your reporting on them is pretty clear. you could definitely submit your findings as tickets without much more effort than you've put into starting threads here, and it'd definitely be a help.

because of the nature of open source, in contrast to the controlled hardware environment of the early bebox, there are a lot more pitfalls toward building robust and stable software that will work for everyone -- hell, after twenty years, linux is finally cleaning up its graphics stack in spite of having powered some of hollywood's leading vfx studios.

sorry to have gotten off on the wrong foot.

I don't get it. It's one thing if you're already a Haiku enthusiast and you desperately want to DO something with your computer. Sure, use QT, since there's nothing else.

But let's say you are trying to sell Haiku to someone who has never heard of it. Are you going to say, "install Haiku and you will be able to run a handful of the same apps that will run on your Windows, OSX or Linux box already"?

If we had a full chrome/html 5 compliant browser on Haiku, consequently, we could also have a lot of more users than now. I know a lot of people (also in the real life) which, when i show Haiku, they say "wow! Haiku seems very fast and impressive, but what about something like chrome/Firefox/Office suite?" Haiku aims to be a Desktop OS, and a Desktop os is oriented to average users, in fact :-) And again, an average user wishes - at least base software like a browser and an office suite - available by default.
Instead, if an average user will try out Haiku without to see his favourite software available by default, will say "Haiku has a lack of software" i read and i hear this assumption a lot of times. I don't say "fill Haiku with a tons of crap/useless apps" but just include that which can give benefits to users :-)

Yeah, Haiku is still in alpha stage, but personally, at home i have three computers. On the main PC, Haiku is the only OS.
This for some reasons:
The first, obviously, because i love Haiku and his performances. The second reason, since on that computer, Haiku is the only OS, obviously i want to do the same things as the other computers/OS: download files via Qbittorrent, streaming videos using SMPlayer+Mplayer (MediaPlayer atm is not able to stream audio and videos), i am productive using Scribus (i can also import SVG and export PDF), i can connect to various IM services using Vacuum. Thanks to these Qt applications, i am able to use Haiku as every day OS. Thanks to these optional Qt apps, some friends of mine, now, wish to install Haiku on their computer :-)
But i'm not saying: go only with Qt and leave/reject native apps. At the moment, with native apps. we are not able to do the same things (or not on the same way: i speak about "completeness"). When we'll have more/stable/complete native apps, be sure that I'll totally switch to native apps, since on my main computer, Haiku is the only OS. As you said, i hope that when R1 will be released, there will hopefully be a complete set of native apps which are as good as any to be found on the other platforms. But in the meantime, i am glad to use multiplatform apps, so i can use Haiku every day :-)
In the meantime, since on my main PC, Haiku is my only OS, i am also glad to do bug hunting and propose enhancements. But without apps i can't use an operating system :-)

As others have said, Qt is not part of the long-term vision of how the OS should look like. That doesn't mean it isn't good to have, and of course it's nice to use Qt apps as a fallback when nothing native can fill the gap. But with the limited resources Haiku has (both in term of money and manpower) spending these on Qt would not get R1 any further. So the money was spent on other things to improve the OS itself. Note that this also helps Qt indirectly: the upgrade of HaikuPorter and the package system make it more easy to install Qt apps in Haiku. We have a recipe working for Qt, by the time R1 is released we should have a package and a good set of Qt apps available in the repos - but probably not installed as part of the default system.

We are also doing a lot of filtering of applications that get in the repos. Previously, the best place for getting Haiku software was Haikuware, but this included many outdated applications, built for BeOS or older versions of Haiku. The repo system will allow to remove these from the distributed packages, and anything you can find in the repo for your version, will work with your Haiku install. I hope this will help everyone better see the state of our software offer, which is not as small as you'd think for such an OS.

Also, remember we can attract some users from AmigaOS 4/MorphOS community. They are worried about the increasing difficulty to find PowerPC hardware, and Haiku may make x86 computers finally look good enough for them. They are used to somewhat limited software offer, and share some ideas with us on how a computer should work. With an initial user base made of BeOS nostalgics, Amiga/MorphOS veterans, and people that gave up on Mac OS X/Ubuntu, we should be able to reach critical mass and start the more users > more devs > more apps > more users cycle.

Unfortunately modern software is not only simple - it always freakin' gets in the way and it's treating me like I was incredibly stupid or something. Software should be designed in a way that's good for power users and simple. It should enable user to get things done quickly and easily but without limiting the user.

That's why Windows is pissing me off. It enables me to do stuff easily and access a large base of software I love to use but... it often gets in the way, especially now, when Windows 8 was released.

That's also why Linux is pissing me off too. The power user in me is very happy with this software, but sometimes open-source/Linux-specific software devs are so eager to complicate tasks that should be very simple with UI which is completely unfriendly (LibreOffice, GIMP, etc. good software, good capabilities, UI gets so much in the way of my creating process I simply CAN'T STAND IT).

And there is an opportunity for Haiku here. It's already a very simple, elegant, minimalistic OS which never gets in the way, with very consistent philosophy of use, but unfortunately incomplete so much - I lack software, hardware support - I can't use it... yet. Because I want to believe there would come a time when Haiku would be my main OS and I'll be very proud of being its user.

Many good points have been made in this discussion.

Here are some items I would like to stress from an user view-point:

0) HaikuOS builds on BeOS which was conceived with a fresh view on the future - back in 1995 or so. That future - centered on an indexed database/metadata file system, efficient handling of media file, and high responsive to user input - is still pretty much ahead of us.

i) BeOS/GCC2 compatibility

This should be maintained as long as the only available "office suite" is Productive 2.x. There are other worthy applications which have not been recreated for HaikuOS/Latest GCC but the lack of an "office suite" is the one which hurts me the most.

Productive offerred something fresh/new about handling documents and media and I liked it despites inherent quirks. There are already too many clones of MS Office and for those - I would go to a Linux distribution.....

ii) Reference information

The only comprehensive book is the old "BeOS Bible". Yes, one can search the web, etc. but it is not much help when one can't get the internet connection to work on a first install.

iii) Capable of running on "older" systems

At home, I will not be able to install HaikuOS on the main (shared) system.....can only used the previous one and even then.....

Maybe one could get a main OEM to produce a HaikuOS "certified" configuration?

Hi Octopus!

Could you elaborate where the (German) localization doesn't work yet? That should be fixed.

Regards,
Humdinger

All the localization settings are in the Locale preferences. There you can choose first and secondary languages and have some formatting options. In the Keymap preferences you'll set the keymap and in Time prefs the timezone etc.
Lumping all three together isnt sensible IMO. But since these settings aren't changed regularly, I think that the current solution, where language, formatting and keymap are set in the FirstBootPrompt panel, is sufficient. This leaves just the time/timezone setting, which is currently not handled by FirstBootPrompt. Maybe that should be included there as well.

Regards,
Humdinger