Do you remember 32-bit User Mode, I came up with a strange idea. What if, such a BeOS / HaikuGCC2.95-compatible User Space could be part of the Haiku 64 bit system, based on a container (VM derivative). You would need a program that manages and controls the Docker.
I ask for constructive discussions, I know that this idea needs a lot of work, but from what I know now it is possible to implement.
Docker and containers are buzzwords since a while, but i cannot seems to find the point, what could it bring to us. Can you explain it?
Why container, docker, layer over layer, if we can have a normal, user installable gcc2 compatibility package? If somebody needs it, can install it, and thatâs all.
The gcc2 ABI wonât be main priority after R1, so why porting docker, develop a container stuff, with tricker and magic, invest manpower, if it is just a compatiblity package??
My idea inspired by two things (sorry but itâs in polish)
I know this s/f @ now, but I think is good idea for future
I also donât get the point for using Docker here. We donât support any kind of virtualization and even our support for the most basic chroot() is limited and has known bugs. And anyway, running legacy apps do not need an isolated container. You want these apps to still be able to access your filesystem and everything, not run in some kind of sandbox. So, a Docker-style container sounds like it would not bring us any step further (it is just an extra layer above the things that need to be done anyway - like enabling a 64bit kernel to run 32bit apps in the first place), and would also get in the way of actually making things work?
Sorry, but Iâm not up to date with the events of Haiku.
I do not know how your compatibility pack works, will it work on emulation, something like
XP Compatible mode from Windows?
My solution is fairly simple, the container is the system version, with gcc2h, pre R1
On which we can run old programs and use Docker to run it in R1 or later version of Haiku. I know this solution needs a lot of work to create but it seems to me that creating a compatibility package will not be easy either.
The point is (AFAIK), that one can create a hybrid haiku image with x86_64 and x86_gcc2 support. Then it will be native support for old binaries.
Not everybody like to see and have a contamined haiku image (there are some legacy-antibelievers here), so the next stage could looks like: outsourcing every bits of gcc2 support to an own package. Then everybody who needs it, can have it, but who donât, can have a vanilla haiku without legacy stuff.
But if we do want to use some kind of container to solve this problem, then somebody needs to port/develop a container system, develop a ârootless Xâ like seamless integration for gui stuff (you do like drag and drop from tracker, right?) It is really hard to do correctly, if you have an virtualized system (not impossible, check VmWare Fusion Desktop integration, what does the same with windows program on macos). The running programs wouldnât show up in Deskbar, no Drag-and-drop, no window stacking with non-legacy windows, no copy-paste, etc. To support theese features plenty trickery and manpower required. And it would be a castle made of cards, it can breakeverywhere. All the time.
Surely, after developing the container system, the first screenshot about it would pop up shortly as a proof that it is possible, but to do it correctly is an extreme task.
Ofc, nobody would say: donât work on container support for Haiku, it could be some realistic use cases for that, but AFAIK the gcc2 compatibility support not one of them.