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)
and Vmware announces application rollback between VM (I have no source for this information).
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.
- no emulation or virtualization required, the programs could be run native.
- haiku packages already have “rollback” feature
- first you need to have a x86_64 + gcc2 hybrid image, then trim it to the roots. It is surely plenty work, as for gcc2 ABI support every supporting libs and thing have to be compiled with this feature in focus (FIXME). If somebody starts to working on this field, the most important thing is to keep the contact surface to the host OS (x86_64) so small as possible, so then the work to keep things work could be minimalised. And as long as there is no breaking change in the kernel code, it would work (maybe through R2… R3 too). We can have a dedicated, clearly defined API in the kernel for this, feature-freezed after R1, so no changes would happen here (idealistic, i know).
- it would work only on x86 compatible hosts, so no gcc2 stuff on ARM or SPARC, etc…
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.