x86_64 hybrid aka beos_compat

[kallisti5]

After some spitballing with Ryan, it would be great if we could finally drop gcc2h for an "x86_64 hybrid" image.

Ideally:

• We build x86_64 hybrid (with *just* core system libraries as gcc2)
• The BeOS gcc2 compatibility binaries get packaged into an optional "beos_compat" package
• Install beos_compat, you can run legacy 32-bit BeOS Application binaries.

Limitations:

• Replicants?
• BeOS drivers wouldn't work... then again I know nobody actually doing this. (Haiku's drivers are better)

[waddlesplash]

it would be great if we could finally drop gcc2h

We need to keep a 32-bit build, as a significant portion of our users are on 32-bit legacy hardware. So even if we switch to gcc7h or whatever, 32-bit is staying for quite some time.

[cb88]

The only BeOS driver I ever touched was the transmeta longrun driver... there may be source for for a SCSI driver or so out there for actual hardware, that would be nice to have ported but not that important in the long run I guess.

As far as network hardware the FreeBSD layer seems to be doing well there... though I wonder as they drop older hardware how hard would it be to keep those drivers working on the compat layer (eg 10Mbit cards some people may have knocking around in thier 32bit boxes, potentially in newer ones but who are we kidding!).

Why would replicants not work? differences in Tracker and app_server? Couldn't you get around that by running a mostly 32bit system on a 64bit?

In the spirit of spitballing, If you are going to bother being able to have compat libs etc... could we make it so that you can install any other arch and have the kernel call a static qemu-user to handle it? That way even x86 apps would work on ARM/Sparc etc... at least to some degree probably enough to be useful. Linux does this via it's binfmt_misc infrastructure.

[kallisti5]

Why would replicants not work? differences in Tracker and app_server? Couldn't you get around that by running a mostly 32bit system on a 64bit?

If tracker / desktop are compiled with gcc7, the gcc2 add-ons / replicants won't work. There was a big ABI breakage after gcc2.

[kallisti5]

We need to keep a 32-bit build, as a significant portion of our users are on 32-bit legacy hardware. So even if we switch to gcc7h or whatever, 32-bit is staying for quite some time.

This statement seems to clash with most operating system distributions. Linux distros are dropping 32-bit x86 pretty quickly nowadays. I doubt that they're doing that with no sampling data supporting it.

No doubt 32-bit Haiku is still useful to folks today, and continuing to offer a 32-bit release while others don't is a good tool to attract more users... however with our pool of developers shrinking, we really do need to "cut time costs" wherever we can.

I'd advise anyone wanting to keep using 32-bit x86 Haiku to step up and help out wherever they can (testing, sysadmin, development, etc).

[cb88]

I'd advise anyone wanting to keep using 32-bit x86 Haiku to step up and help out wherever they can (testing, sysadmin, development, etc).

Really this comment doesn't make a lot of sense... Afaik 32bit gcc2hybrid is still the primary architecture for Haiku with 64bit almost able to be a viable main architecture. This bug report wouldn't exist if 64bit Haiku was fully ready anyway.

Also several other developers have commented on this very issue before, maintaining 32bit is a minimal effort. Especially so since amd64 is just an extended version of x86. Killing off 32bit support in Linux distros etc... is a symptom of bloat, and poor maintainability.

[kallisti5]

Keep in mind there are a lot of hidden costs here:

• Maintaining gcc2 support for Haiku
• Maintaining gcc2 support in haikuports patchsets.
• Infrastructure costs:
  • ~40% of the nightly builds are 32-bit gcc2 (293 GiB)
  • ~50% of the nightly repos are 32-bit gcc2 (81 GiB)
  • x86 secondary packages in addition to x86_gcc2 primary packages.

However, yeah.. a lot of these issues would persist in a gcc2 hybrid "add-on" approach. I'm just always trying to find ways to cut down our workload.

I'd advise anyone wanting to keep using 32-bit x86 Haiku to step up and help out wherever they can (testing, sysadmin, development, etc).

Really this comment doesn't make a lot of sense... Afaik 32bit gcc2hybrid is still the primary architecture for Haiku with 64bit almost able to be a viable main architecture. This bug report wouldn't exist if 64bit Haiku was fully ready anyway.

This comment makes complete sense when you look at who makes decisions for the project (contributors). The more people who contribute who support 32-bit Haiku, the longer it will stick around ;-)

[waddlesplash]

The more people who contribute who support 32-bit Haiku, the longer it will stick around

There is, as cb88 noted, no maintenance cost (aside from the disk storage) on 32-bit. So it will stay around until there is some feature we want that we can't just if 0 out on 32-bit. Which may be never.

[pulkomandy]

Hi,

It's fun to read that "32bit users should contribute more instead of complaining". I'm still running only 32bit systems here even if my hardware is 64bit able.

This is valuable to me as a developer because I'm still occasionally running old BeOS stuff (SynC Modular, but a bunch of things from HaikuArchives as well, lastly I started toying with BeDC which is a nice base for a syslog analyzer, unfortunately the app itself is closed source, I'll consider a rewrite if I start using it regularly).

We should still finish and merge the 32bit compat for 64bit systems. And I would be quite happy to drop both gcc2 and 32bit support at the same time, when that times comes. I think it's still a bit early for this, given that the maintenance costs are not that high. I'll accept that people do not care too much about gcc2 compat and that we start moving more and more things to gcc8 (as is done for WebKit, for example - app_server would probably be next because of HarfBuzz if we want to integrate the complex text rendering work).

I'd say we can handle this small steps at a time, when there is a good justification to do it. We can also see when users complain and try to fix things (rewrite the apps/drivers/add-ons that need to be replaced, in the worst case).