Haiku OS Advances With New Official Release

[Awesomeness]

PAE? is it a 32 bit OS only?

GCC 2 must be some kind of joke.

For Haiku 1.0 the developers target close to 100% BeOS compatibility. As you may have forgotten, with GCC 3.0 the C++ ABI was changed which means that all C++ applications had to be recompiled in order to work again. For that reason Haiku is ? so far at least ? stuck with GCC 2 and 32 Bit mode.
However, Haiku is built to be compilable with GCC 4. It's just not the supported way to do. As for compilation as 64 bit OS: Could be that that's possible, too, but ? again ? not officially supported. I don't know about this, though.

[cb88]

There has been some work done on 64bit support however the drivers have not been ported and such so no you can't build it as 64bit yet... but it is on the TODO list.

For what its worth Haiku has been compiled with LLVM by a few people however I don' think it is directly supported by the build system yet.

So you might say that GCC2 support is a good thing as it means the code is portable. Pfft netbsd still buits on GCC2 after all and its gets respect seriously don't diss an OS cause it supports MORE compilers.

[V!NCENT]

According to a poll asking for what was a requirement for ending R1, was Gallium3D and WPA (and some other things).

I think any OS should now ditch GCC for EkoPath anyway, especially because Linux only needs one tiny patch and EkoPath supports GnuC anyway.

Anything not x86 or Itanium? LLVM for the long run. Gnu gives two fingers to standards. I mean... GNU C? WTF... Non-complience and bugs everywhere...

[allquixotic]

Ah, the fun of hobby OSes. If this is how a small group of hackers want to spend their time, they're more than welcome to.

I personally wish they'd work on Linux or a Linux-based desktop suite, but hey, I can't tell them what to do with their spare time.

[allquixotic]

I think any OS should now ditch GCC for EkoPath anyway, especially because Linux only needs one tiny patch and EkoPath supports GnuC anyway.

Except that EkoPath is literally chock full of internal bugs and errors, even when trying to compile unoptimized plain C code with no hand-coded assembler.

For instance, today I tried to compile liblcms2 and got a bunch of really cryptic errors about the output of their x86_64 code generation, something about the wrong number of operands for an instruction! And from following #pathscale in IRC, it seems that these kinds of problems are extremely common, everyone is experiencing them, and the PathScale devs don't react to this kind of inquiry.

For instance, I asked for help there with my liblcms problem and was silently ignored, even though I provided a pastebin link to the compiler output and described what I was trying to do. lcms is an integral part of many desktop applications, because it has utility functions used by, e.g. the libopenjpeg decoder. And I don't think that lcms triggering a bug in pathcc's codegen is an outlier; it's closer to the norm.

Also it's been a week since Larabel spilled the beans on EkoPath and they still haven't pushed the code. How hard is it to host a tarball or open a new github repo? I mean, I totally understand if they're trying to get permission to redistribute third-party code, but if the copyright is all theirs, it should be a no-brainer, taking a couple of hours at the most to assemble the files and push them. They could at the very least make a distribution of the ekopath binaries without the trialware / license activation nonsense and just make it freeware for the time being.

[XorEaxEax]

I think any OS should now ditch GCC for EkoPath anyway, especially because Linux only needs one tiny patch and EkoPath supports GnuC anyway.

Lol wut? You obviously haven't tried compiling stuff with Ekopath if you think it's anywhere near a drop-in replacement for GCC. Also, having now run Ekopath on a number of benchmark tests I can tell you that the cherry-picked test results from the Phoronix benchmarks are not something you can expect in general. In some tests it wins out, in some tests it loses to GCC, in many they are very close, in many ekopath sadly fails to compile and often suffers internal crashes.

Anything not x86 or Itanium? LLVM for the long run. Gnu gives two fingers to standards. I mean... GNU C? WTF... Non-complience and bugs everywhere...

What exactly are you referring to? Compiler extensions? And bugs everywhere? Compared to what?

[XorEaxEax]

For Haiku 1.0 the developers target close to 100% BeOS compatibility. As you may have forgotten, with GCC 3.0 the C++ ABI was changed which means that all C++ applications had to be recompiled in order to work again. For that reason Haiku is ? so far at least ? stuck with GCC 2 and 32 Bit mode.

Yes, I'm not sure I agree with their choice in this since while it probably made sense at the time, when Haiku 1.0 finally ships I doubt there will be much interest in Beos legacy apps. And since the Beos/GCC2 compability will be deprecated post 1.0 anyway, why not make the break right now?

However, Haiku is built to be compilable with GCC 4. It's just not the supported way to do. As for compilation as 64 bit OS: Could be that that's possible, too, but ? again ? not officially supported. I don't know about this, though.

Actually Haiku is continously being built with GCC 4 and served up as nightlies. Also GCC 4 is supplied with the Haiku Alpha's although it defaults to gcc 2.95. You can change this with the command 'setgcc gcc4'. Again I think it would be wise to switch fully to GCC4> now rather than wait for final r1, but that's just my personal opinion. As for 64bit, there was work done on that during last GSOC but I don't think the guy got very far, the project didn't get anywhere near finishing. My guess is that someone like Ingo (kernel dev extraordinaire) will have to do it, a good candidate for a future development contract imo.

[Awesomeness]

Yes, I'm not sure I agree with their choice in this since while it probably made sense at the time, when Haiku 1.0 finally ships I doubt there will be much interest in Beos legacy apps. And since the Beos/GCC2 compability will be deprecated post 1.0 anyway, why not make the break right now?

They defined a sane roadmap and they stick to it without any ?mission creep?. I think it's very admirable. Many projects die or almost die because of lack of a clear vision.
For quite some time user-space components were developed inside BeOS 5. So GCC2 was the only possible choice anyway.

In the long term I'd guess Clang will be the preferred choice simply because the developers like BSD-like licenses more.

[allquixotic]

Lol wut? You obviously haven't tried compiling stuff with Ekopath if you think it's anywhere near a drop-in replacement for GCC. Also, having now run Ekopath on a number of benchmark tests I can tell you that the cherry-picked test results from the Phoronix benchmarks are not something you can expect in general. In some tests it wins out, in some tests it loses to GCC, in many they are very close, in many ekopath sadly fails to compile and often suffers internal crashes.

So I'm not the only one with this crashy experience If I paid $1795 or more for a compiler license and it crashed internally as often as EkoPath does, I would want a refund. No wonder they open sourced it.

[XorEaxEax]

In the long term I'd guess Clang will be the preferred choice simply because the developers like BSD-like licenses more.

Actually, from what I've gathered during the mailing-lists discussions they are (atleast the key devs) not very licence opinionated but rather pragmatic. For instance they stick with bash (GPL) rather than any bsd licenced equivalent due to the compability it offers. There are some devs like pulkomandy who seem to be very licence-oriented but I'd say he is hardly the norm.

Also it should be noted that the reason Haiku (or OpenBeos as it was called then) chose MIT licence for the project was not ideological but practical. Back then they wanted a permissive licence because they were hoping for a commercial (and thus potentially closed source) pick-up of the project.

There's certainly the possibility that clang/llvm will replace GCC as the 'shipped-with' compiler for Haiku, but if so I'm certain that will be a choice made on technical grounds, not ideological.