Again I know this is a lot of work but it’s going to need to be done someday, unless they really do think they will stay 32bit forever, so they might as well build on the 64bit base rather then slip it in as an afterthought. 64bit is the norm and I soo dearly want to see BeOS alive and well no matter what it’s name might be, but I also don’t want to have to keep old crappy machines kicking around to use it, nor do I want to have it omit half my machines spec to function.

I think we all want BeOS to rise and kick serious ass, and I just don’t think a 32bit code base can pull it off as everything is 64bit and things are pushing the need to address more and more memory space. This doesn’t mean Haiku will be a pig on system resources to need to utilize 16gigs of RAM, it just means if I have 16gigs of RAM in my machine I want to use it. I didn’t buy 16gigs of RAM to use 4gigs.

I’m sure we can expect issue with obscure or bleeding edge hardware but utilizing RAM or or full CPU potential is so base I don’t see how this can be an omitted focus. We’re on 64bit chips, so let’s use 64bits, not 32!

I was trying to say that if Haiku (or any other OS/Kernel) is 64 bits it (application or OS/Kernel) wouldn’t be limited to the 4 Gbyte memory limit (whether per application or as seen by the OS/Kernel).

Am I wrong ?

About your point on the 64 bits topic: I think you tell us that at the time R1 will be released 4Gbyte+ configurations will be commonly found (as they already are affordable today). So you think we should not make Haiku (seen as) “limited” (if it still is 32 bit at that time there will be a need for a “hack” hiding the unusable memory to the OS/kernel and applications). You think Haiku should be focused on the future.

Again, am I right ?

I was just trying to summarize the information without taking a position about the “strategical” question: should Haiku go 64 bits (ASAP)…

I’m not sure what you mean about the “if using 64 bits there would be no such barrier” since that’s a broken sentence but the point is while the kernel could be limited like the BeOS kernel hack they came up with tie limit RAM to say 512mb to keep it from KDL’ing? Why would you want to limit or break things right off the bat. Haiku is not even at Alpha 1 yet but risks being left behind without crippling itself to function on stuff that being sold all over the place. You can buy cheesy stock OEM machines at Best Buy now with 6 gigs of RAM, but a 32bit OS won’t handle that.

The Haiku Gazette article also doesn’t make sense as the translation leaves a few things too broken for me to get the gist of. It almost reads like I failed to mention todays 64bit CPU’s won’t run 32bit code but I did say that. My point was by the time R1 comes around, will it even work on common hardware? Or will it require extra code to break and limit things?

I’m well aware of the fact the majority of the 64bit CPU in the wild are running Windows XP 32bit and even Vista 32bit, but that’s right now. I’m seeing more and more media center machines and gaming machines hitting the common shelves and they are leaving the 32bit Vista behind for the 64bit as the machines are shipping with 4+ gigs of RAM.

The Haiku Gazette article in #4 (again the translation is rough) makes it sound as if these are reasons to stay 32bit, but why? Do they plan on staying 32bit forever? I don’t see the purpose of hanging on to this, get over the hump move to a 64bit addressing space, and focus on what Be was about, forward looking.

Hum… i will be very angry if Francois is the father of my son….

Laurent
Webmaster of ljr.free.Fr/blog