Hallo everyone,
I am following haiku from day one and before that I was using the real BeOS
from release 3. So I like what you do, developing my dream OS.
HaikuOS needs to break free, breath and grow by itself. But we need to make
some important changes. It may be our last opportunity.
We allready know that one day we are going to change to gcc5 but we are not
willing to sacrifice the gcc2 code yet, because it is our most valuable
effort so far.
In my opinion haiku in the first stage needs
1. to run on a modern hardware. (Hardware accelerated graphics I can do
without)
2. it has to be a native 64bits OS.
3. a Webbrowser (chrome based like icecat as it will deal with all the web
standards etc).
All the rest will come as more and more users work with the OS.
Now regarding the decision makers I suggest:
All members will have the right to vote and then the developers will have
to vote the implementation of each and every feature on the list. This is
the best of both worlds.
//Eftimios
tis 6 dec. 2016 kl. 17:00 skrev Adrien Destugues <pulkomandy@xxxxxxxxxxxxx>:
6 décembre 2016 16:47 "Donn Cave" <donn@xxxxxxxxxxx> a écrit:
Quoth "Adrien Destugues" <pulkomandy@xxxxxxxxxxxxx>,
...
What we can do is let people raise their concerns (as they did
in this thread). What we have gathered:
- Some people think we should go 64-bit only and legacy-free,
to attract new devs who run away screaming when they hear of gcc2,
- Some people think we must keep GoBe Productive running at all costs,
- Some people are still using 32-bit only machines and plan to
continue doing so for the next 5 years.
On the horror of gcc2 - you might be able to deal with this
in a minor way by simply changing the default. Like the
"setarch x86" in my .profile. An easy choice that people can
make, with the default pointing towards the future. That
should communicate your intentions more clearly to developers.
That's not the only matter here, that would be too easy.
At the moment we have not committed to making the gcc5 ABI stable and
supported. This means we can break it at any time, by changing the API,
replacing the C library, switching to a different C++ coompiler, etc.
So, in theory, people distributing applications should stick to gcc2 only,
as that is the only way to ensure their applications continue to run on
future Haiku versions.
Making gcc5 the default compiler but then telling people they need to use
gcc2 if they want to distribute their apps makes little sense. And a lot of
applications are already ignoring this constraint (anything using Qt, for
example).
This means our options are:
- Pretend the problem does not exist and continue to advertise gcc2 as the
only supported ABI,
- Stop making any promises about ABI compatibility,
- Do the required effort to make sure the gcc5 ABI is "stable", and only
then advertise it as the default.
I'm trying to go with the third option, with the gcc5 ABI becoming stable
at the moment we release R1. This leaves us with some time in the beta
release cycle to make sure we are ready for that, including future-proofing
the ABI (adding FBC padding, etc) so that we can continue to support it in
R2.
Moving to gcc5 too fast, without these precautions, would force us to
break all gcc5 apps in the near future. It seems better to take our time to
perform the transition so that it happens more smoothly for users.
--
Adrien.
