Haiku OS Advances With New Official Release

[RealNC]

C'mon... GNU adheres as much to C as Internet Explorer adheres to W3C standards. The amount of times I have seen releases passed while having 'complience regressions' is insane.

From http://gcc.gnu.org/onlinedocs/gcc/Standards.html

For each language compiled by GCC for which there is a standard, GCC attempts to follow one or more versions of that standard, possibly with some exceptions, and possibly with some extensions.

Yes, unless you specify that you don't want the extensions. -std=c89/c90/c99. There's also -ansi and -pedantic.

Suggesting that GCC is not following standards *on purpose* is just plain stupid though.

[curaga]

How is it lock-in if there's both documentation and code?

[V!NCENT]

I'm not saying GCC avoids complience on purpose. If that's what you think because I've compared it to IE than that's incorrect. The development team was fired and is now in persuit of following standards (with BS extensions). Hell Windows 8 will use WebKit. You could as well compare it to FireFox.

I am just baffled at the releases. Shipping without full complience OK, but releasing new versions knowing you reduce complience is downright rediculous. What were the thinking?

Sure the is GCC optimized code. Sure EkoPath has never needed to compile non-supercomputer stuff or proprietary stuff from the beginning. But they target complience. For all we know what doesn't compile is not complient? (not stating that though)

But I've seen it elsewhere with GNU projects. For example KDE4 just does everything OpenGL the right way while Gnome 3 wants a ugly but working solution with the FLOSS drivers.

I don't get it. I would retract my complaints about GCC if they were to just focus on full complience before anything else.

About that lock in product; it's not lock in vendor. But can I compile GNU C with IBM C for example because I might like that compiler? No! What options do I have? Repackaging GCC? What good is that if I want a different compiler?

[Awesomeness]

Hell Windows 8 will use WebKit.

Whatever drugs you take: Stop it for your own good.

[Awesomeness]

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.

bash is a simple user-space program that's not linked to by anything.
Once the Haiku devs feel to have the luxury to care about debugger integration in closed source IDEs, Clang is the natural choice as gdb simply can't be as tightly integrated into a non-GPL IDE.

Sure, today it's a low priority since GCC (2&4) work and the devs rather concentrate on more important stuff. So unless their attitude changed dramatically over the last 10 years (didn't follow that closely in the last 5), Clang will come as preferred compiler at some point.
Considering that even the today's “pragmatic” (and disillusioned about closed source adoption) devs still only port drivers from BSDs rather than Linux (even though Linux is often directly supported by the hardware vendors), it's pretty clear that they are not as “pragmatic” and “unideological” as you present them. The “pragmatic” way would be to simply get the best drivers and port them over no matter where they come from and no matter their license.

[XorEaxEax]

I'm not saying GCC avoids complience on purpose. If that's what you think because I've compared it to IE than that's incorrect. The development team was fired and is now in persuit of following standards (with BS extensions). Hell Windows 8 will use WebKit. You could as well compare it to FireFox... etc etc

I'm leaning towards Awesomness conclusion, stay off the drugs, son!

As for GCC offering compiler extensions, the reason Linux is chock-full of them is because the Linux kernel devs REQUESTED most of them from GCC in the first place. Hell, way back Linus was pissed because he felt GCC wasn't adding his requested extensions fast enough.

Now let's flip that coin, would the kernel devs have wanted these on a whim? No, they wanted them so that kernel development would be made easier and that they would be given better control of what code the compiler would generate.

This allows the kernel devs to benchmark their code for cache locality, branch-prediction etc and then give the compiler detailed instructions using extensions controlling that behaviour so as to maximize performance without resorting to assembly code.

That other developers outside Linux kernel development also finds these extensions desirable and choose to use them is also obviously not the fault of GCC.

Developers requested (in Linus case 'demanded') these extensions, as such developers will use these extensions.

If other compilers does not support these extensions, they will not be able to compile code in which the developers of said code CHOSE to use said extensions.


Now can we get back to Haiku here, plz!

[XorEaxEax]

bash is a simple user-space program that's not linked to by anything.

Yes that's exactly to conclusion the devs had, while it would not be practical to include GPL licenced code into Haiku's core systems, here it makes no difference and as such the licence made no difference. And looking at Bash and the competing offerings, the practical/technical choice was to stick with bash due to compability.

Once the Haiku devs feel to have the luxury to care about debugger integration in closed source IDEs, Clang is the natural choice as gdb simply can't be as tightly integrated into a non-GPL IDE.

I fail to see why the Haiku devs would switch compiler toolchain in order to cater for the possibility of a future 'closed source IDE'...

Considering that even the today's “pragmatic” (and disillusioned about closed source adoption) devs still only port drivers from BSDs rather than Linux (even though Linux is often directly supported by the hardware vendors), it's pretty clear that they are not as “pragmatic” and “unideological” as you present them. The “pragmatic” way would be to simply get the best drivers and port them over no matter where they come from and no matter their license.

Well, obviously they are not going to change Haiku's licencing from MIT to GPL, so any GPL code will have to be held outside the Haiku core system, hence them porting BSD drivers. The compiler however, falls under the same category as bash, it does not affect the licencing of the code it generates so the decision to use it is purely a technical one (compability, performance...). And there are GPL licenced drivers in Haiku (ntfs driver spring to mind) but you have to enable and build them yourself, again making sure that Haiku does not ship linking to any GPL libraries.

MIT/BSD is obviously the preferred licence of the Haiku devs, else they would have switched ages ago, but as has been shown, Haiku is not about THE LICENCE. Where the licence have no effect on the core Haiku system, the best/practical open source solution is chosen rather than the one where the licence best correspond with MIT.