Haiku has an opportunity to blaze a path to the future of personal computing because they’re designing a new operating system from scratch. Back in 2001, when BeOS went under, it seemed logical at that time to reimplement the BeOS experience and make Haiku backwards compatable. Now, some 13 years later shouldn’t Haiku developers consider rethinking their objectives? I believe Haiku should blaze a path to the future with consideration to modern computing trends, hardware support, and a user experience different than Windows, Linux or Mac. Forget about porting apps to Haiku from other operating systems and instead make Haiku something unique.
Back in the day the BeOS buzzwords were symmetric multiprocessing,pervasive multithreading,preemptive multitasking and a 64-bit journaling file system.
What is Haiku offering the computer user that the others don’t?
Exactly. First of all they need to let go GCC2 finally, it doesn’t make sense and it’s a joke in 2013-2014, for goodness sake. Feeling lack of the apps? Port Qt5 and apps based on this framework. All of the ported apps are better than old time ones made for BeOS 10 to 15 years ago.
But really they need to decide what are they really doing. Modern, bleeding-edge OS leading the way or Legacy-OS with layers and layers of backwards compatibility, btw that is what JLG and Be inc were all against, working on BeOS. Back then they’ve pushed it to be as legacy-free internally as possible.
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.
IMHO modern system must have a modern compiler (gcc4 or clang).
The only reasonable scenario in my opinion is to make a compatibility layer in the option package.
If you want use the old BeOS (gcc2) software, you can install the compatibility layer from the Depot.
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.
Get the futur 'ama), Haiku gcc2
R0.5 Bottle ;
GET THE FUTURE, - NO GET BACK old gcc…
R1 - GCC 4.x
- getback Full access RW!;
++ good stable;
++ good drivers;
3dEyes, aren’t you the one you did NaviTracker back in the day?
Today, the hardware trend is 64 bit OS, running on multicore processors, with parallel GPU’s etc. If Haiku is to succeed, it must be able to fully take advantage of all the modern hardware available to the average user. I say dump the backwards compatability with BeOS now, and build a solid foundation for the future. Nobody would build a new house on an old foundation, and neither should Haiku.
it has multicore support out of the box (i’ve no clue about multiproc support, anybody have a workstation to test it on? or a single cpu with more than 8 cores/threads?)
there is a 64-bit kernel with nightly builds running gcc4
there is a 32-bit kernel with nightly builds running gcc4
alpha4.1 has a hybrid gcc2/gcc4 environment
also, language may help to facilitate certain software design, but software design itself is language agnostic and whatever compiler is present has no bearing on the socalled modernity of applications written.
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.
[quote=jua]
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.[/quote]
Haiku most build-to-build anywere run’s probanly, GPU drv - pisdets on real hard,… were he ih work?)
1,2,3 pc’s?
Haiku is a direct, native reimplementation, there are no “layers and layers of backwards compatibility”[/quote]
So you choose Legacy OS, okay.
In spite of agree with some questions, I have a different point of view about this. Since its beggining, Haiku - so called OpenBeOS - was thinked as a replacement of BeOS. The goal was (and its is yet) total compatibility with BeOS’ apps. I think there is no problem with this. The project is supported and developed by BeOS enthusiasts (BeGeistert, the main “meeting point” of the Haiku community, means “enthusiast” and refers clearly to BeOS). The Haiku devs is working since 2001 to get that first goal with the Haiku R1 final release. I understand this perfectly.
To me, Haiku R1 will be the turning point of the project. From this, a world of possibilities will be open. Remember that the OS is MIT licenced. So, somebody can create a fork or a new OS based on Haiku. From the final release the “Glass Elevator” project, that will implement important mods in Haiku UI, can be resumed. With a community support OS, some devs will feel more secure to create new apps, features and drivers, like in the BeOS’ times.
I believe that this moment will come soon, perhaps next year. Haiku is moving to be a modern OS with the efforts like Pulkomandi’s port of WebKit and the new Package Manager. So, some more patience and collaboration is expected.
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.
gcc2 must die /////
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.
Refining multi-core and SMP performance, cpu scheduling, multi-threading, improving media kit and web integration (think about desktop replicants and webapps for example), using some modern tech like gpgpu/opencl stuff for efficient computing could be the priorities for Haiku after they’d dump the gcc2-beos-legacy or whatever nonsense. I just wish there was more new active forward-thinking developers willing to spend their time working on these features. Touch UI is cool, but it’s not the focus, after all iOS, android and other more obscure linux distros pretty much had it covered on tablets. Like with native browsers and Firefox/Chrome party, your little browser could be amazing on it’s own, but average joe wants his usual extensions (in the case of tablet oses it’s the apps). I’d rather like Haiku to make the best of standard or low-spec machines like nettops and whatnot than chasing the touch/tablet bandwagon. Quiet, small, low-power PC and super-efficient OS installed on it, what’s not to love?
In a lot of ways OS X is a good example of modern web-friendly multimedia OS done right. Power efficient, quite fast with hardware acceleration to the max (OpenGL, OpenCL), impressive multitasking and RAM management, excellent usability as expected. It’s now freeware since Mavericks, but it still proprietary software and works only on the official Mac computers or hackintoshes with a few hacks on matching hardware configurations.
It’s just funny when mentioning Haiku to the app makers outside of the community the first thing they ask - is gcc2 still the only “supported” compiler? It’s almost like gcc4 (or, god forbid, clang/llvm) and x86_64 are second-class citizens among the people swimming in nostalgia waters.
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).
Not to nitpick semantics, but - Haiku is already better than BeOS 5! But the competition … when BeOS came out in fairly mature form in 1998 with R3, Apple was still limping along with the old MacOS, Microsoft on Windows 95, etc. For all the good it did them, Be showed up in time to deliver a really superior platform.
Today, it’s a tougher world. In my opinion, the advantage Haiku can hold on to is its simplicity. Innovation is healthy and I expect will lead to good things, but hopefully not at much cost to the unvarnished simplicity of the API in particular.
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
In reply to PulkoMandy:
- We’re not doing a bug-for-bug clone, but a feature-for-feature one.
BeOS R5.1d0 “Dano” has build date of 15 November 2001, the day of Be Inc.'s closure, exactly 12 years ago this month. How close are we to realizing a “feature-for-feature” clone of BeOS?
Back then, I could watch TV on my computer, record shows, and rip VHS tapes to my hard drive using the included TV app. Then I could burn these files to a CD using the included CDBurner app. When can we expect to see these features implemented in Haiku?
- 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
I love to do it now, but the x86_64 nightlys are not as feature complete as 4.1a4. When will we see an official feature complete x86_64 build of Haiku? Alpha 5?
- As for looking into the future: R1 is getting close now. Work has already started towards making Haiku better than BeOS in many ways.
I agree. In many ways Haiku is already superior to BeOS. Thanks to the developers who are making it happen!