[haiku-development] Re: 64 bit
- From: Ralf Schülke <ralf.schuelke@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 10 Sep 2014 11:16:04 +0200
2014-09-10 10:15 GMT+02:00 Simon Taylor <simontaylor1@xxxxxxxxxxxx>:
>
> Will Haiku R1 be relevant to most people? Probably not. Would having the
> release be 64-bit make a difference? Also probably not. R1 is about releasing
> something that works and seeing if that stirs up any interest in evolving the
> ideas into a modern desktop OS. That’s not going to be easy - finding a
> vision for “modern Haiku” without fragmenting the already small community is
> likely to be a massive challenge (one that will require a very significant
> increase in the size of that community, or a very significant investment of
> money from somewhere IMHO).
>
> There’s a lot of threads lately about Haiku needing to change this or that
> aspect to be relevant. The truth is that R1 is going to be seen as “retro”
> regardless of what happens under the hood. It’s going to look like BeOS and
> that’s going to impact the reception people give it. Compiler/CPU etc are not
> going to have a great deal of impact (regardless of the R1 configuration, gcc
> 4 will be supported, and the codebase itself is 64-bit clean).
>
> So let’s just take the path of least resistance to get an R1 out of the door,
> have a massive party, and then see what the mood is about the future.
>
This so true.
For intresting catch new developer, need we this too, nobody will work
an a vision he older then 10 years, because the time and the world do
not stopping. So are the nature of thinks to work in this future not
in the past.
I can not understand why not break all stuff an work on a new version.
The goal can limit and the new stuff too, simple work at first then
focused on stuff. eg:
- remove arch and plattform we are not 64bit
- join one compiler eg: llvm/clang llvm are a good idea and give place
for more future stuff
- cleaning source tree and split the "userland stuff, not the
developerland (compiler, editor etc) eg: apps -> can separately, and
packages system , webkit, can separately -> src/os.. ; src/apps/..,
src/webkit/..; src/server/packages/..;
etc. the results are a clean system from the OS design: KERNEL ->
SERVERS -> KIDS -> [APPS]
- redesign the UI, its better to work on modern colors and shapes with
alpha (or fake alpha) Desktop and UI ideas from chrome os, eg. the
desktop panel are nice and the window management.
- make the kits more usable and stable, so that app developer work on apps.
We can make more then now, its funny to make it better, and this os
need good apps and this os are free and this os are altanativ, because
it is modern.
We can say we are small but complete with less of loc and a vision.
Talking is easy, work are harder, so what will we do?
Let us open a new code tree with a new goals and vision and we will
see whats happens.
> Simon
Ralf
Other related posts:
