Wow how many emotionally charged messages! Initially, I just put a like for proposal, but now I see it is necessary to add some personal words.
For me, HoH64 is the most awaited feature out of all already mentioned. I would rather see 1 version of Haiku x64 able to run gcc2 closed source applications written for BeOS and let obsolete versions die (well, at least this permits to focus on one architecture).
Why is it important? I think that maintaining 32 bit x86 support is not a significant burden. The problem is gcc2 ABI that prevents using modern C++ in most Haiku system framework libraries like libbe.so. Problem can be solved by hard-forking library set needed to run gcc2 applications. It is not related to supporting 32 bit hardware.
Well, I may be not express myself sufficiently clear. Of course, I speak about gcc2 on x64. And I speak strictly about user experience, not developerās. Many users want to use modern x64 Haiku. However, there is no support for x86_gcc2 compiled applications. If they want to use them, they are forced to install x86 Haiku with gcc2 support. Now, it is possible to double-boot Haiku x64 with Haiku x86 to make use of all user needs. But it is much easier to just install Haiku x64 with x86 and gcc2 support.
HoH64 or running old BeOS binaries on 64bit Haiku is a good idea.
Maybe I can finally try Gobe Productive then? 
That topic came up quite often already,so I think many users may want that.
Maybe Iām thinking too far,but I guess that could also help Wine running 32bit applications and make it much more useful as much Windows stuff is still 32bit nowadays.
What I really donāt want to see however is something like Wine for Linux applications,built into the kernel.
Please donāt do that,runtimes for poorly engineered OSes belong into userspace applications (like Wineā¦) and shouldnāt pollute the Haiku kernel with all the needlessly complicated and bloated Linux-specific stuff.
It doesnāt give us much of an advantage anyway.
Most proprietary crap is also available for Windows,so it can be used in Wine,and open-source applications can be ported to run natively on Haiku,so that they integrate much better with the OS and donāt need the resources for emulating (at least parts of) a system that isnāt Haiku.
It can be implemented with optional kernel modules not installed by default. So it will not pollute anything. I think that freedom of choose is important. If someone need to run Linux applications on Haiku, why not?
I still think itās a waste of time and we should at least focus on properly porting software if not write everything natively (which is really too much work for now,unfortunately) instead of relying on compatibility layers for a really awful and chaotic OS that knows dozens of ways for doing every single task.
But if itās not forced on me and instead distributed as a separate package,I can happily ignore that it exists.
I only hope that it doesnāt end up like FreeBSDs compatibility layer that clutters the whole filesystem with virtual Linux directories and needs every library installed twice,once for native applications and once for compatibility layer stuff.
I see that one as a big anti-feature that Iād prefer not to have.
It is not a waste of time because each developer do what they want. If developer wanting to implement Linux compat layer will not do it, it will simply do nothing for Haiku and do something else for another project. Work on Linux compat layer may help to reveal and fix various Haiku problems.
But if itās not forced on me and instead distributed as a separate package,I can happily ignore that it exists.
Thatās the whole point of my design. To not having to bloat the Haiku kernel with anything and to not require people to reinstall the whole OS to get an optional feature, everything comes as optional, installable packages.
Yes. Hopefully Haiku have stable kernel API so it is possible to distribute 3-rd party kernel add-on binaries.
As this post gets some more reacts and some comments other than āthis is useless/I donāt see any usecaseā, Iāll clarify a bit more about this proposal.
I donāt just want to implement execution of non-native binaries, but also integration of these into the environment.
I will implement the simplest (and probably most wanted by the community) case: x86_gcc2 on x86_64 to demonstrate the capabilities of the emulation module. Then, Iāll focus more on the integration.
To solve the primary arch/secondary arch issue, I am thinking of storing the emulated binaries on separate packagefs drives on a chrooted environment. A service should manage integration of these binaries, for example, binding/copying user data folders, creating command-line aliases,ā¦ This way, x86_gcc2 packages can be installed without any modifications and can interact seamlessly with user data.
Running Linux binaries on Haiku, something considered very controversial among this community, is not part of the project proposal itself, it is just a long-term possibility. If this proposal becomes a reality, it might be possible to implement a Linux subsystem that integrates even better with the Haiku environment than WSL does with Windows.
To be honest, while Iām really happy if my main proposal gets accepted, I personally prefer this work more (as I love compatibility layers and things like that). But in the end probably the one that produces more value for the community and aligns more with the interests of core Haiku devs will get selected.
It is not. If the proposal is good we will find a mentor for it. I can speak from experience, because when I did GSoC as a student, this is exactly what happened. The Locale Kit I started then was not in the initial ideas list from Haiku.
So, if you have no idea, instead of assuming things, maybe let the people who run the thing reply? Or read a bit about it, because, as humdinger pointed out, this is all clearly written, either in the GSoC program rules or in our ideas page.
I donāt like the chroot idea much. Iāve opened a ticket wirh alternative aproaches some time ago, maybe it can be of use.
This is not seamless as package structure would need to be changed.
I also proposed dynamic path remapping by packagefs so for example lib/libbe.so became lib/x86/libbe.so when installed on x86_64.
Yes, thatās true.
This would also require runtime_loader to be aware of the new library paths.
It might also cause problems for ancient non-packaged binaries.
We already changed things for non-packaged binaries once, we can do it again.
I think integrating something like @X512ās UserlandVM, or ways to register ābinary handlersā the way Linux does to support qemu-user automatically, is a good idea indeed. If you would want to work on this for GSoC we could certainly find mentors if you had a solid proposal.
Exactly. English isnāt my native language indeed and I try to stay out of any culture wars as much as possible.
But letās apply this to my original post:
s/misinformation/wrong information/
s/scare/turn/
Now back on topic 
I didnāt say THEY were late. I said it was late for additional proposalsā¦ because the propostal date past or at least that is what I had read. and already admitted that I was wrong, and was only replying that out of turn comments being further accusatory towards myself were just that.
You should know as well as anyone else that knowledge on the internet is best effortā¦ Then you and everyone else comes out of the woodwork to further lambaste me. All over freaking getting the semantics of proposal submission wrongā¦ and this misunderstanding was already cleared up BEFORE any of you with negative remarks replied.
Also I stand by the statement that this particular proposal is a bad fit for Haiku even given the further information on how it would work, as primarily adding layer of complexity to a system that doesnāt otherwise need it. And the only example of a system that does implement it being closed source and has only used it very very infrequently (for OS/2 and Unix compat layers in the past but they never got any traction and were dropped). Technically the proposal is an offshoot of those technologies and does differ slightly.
Also lets go into the word missinformation and why it triggered me to begin with.
The defintiion of the word:
āfalse or inaccurate information, especially that which is deliberately intended to deceive.ā
I the context of my first post in this thread is it not obvious why I would take offense to such a word? The way this word is commonly used is to accuse someone of being an underhanded liarā¦ which does not appear to be the actual intent of the poster but even so, it was written in the typical accusatory format.
Also recently Haiku as been loading up on featuresā¦ this is both a blessing and a curse, as you have no doubt noted its no longer the lightweight OS it once was, but its also faster on newer hardware in many cases. Any major feature like this probably should be met with a lengthy developer discussion on its meritsā¦ which again puts this particular suggestion in 2024 in any practical sense.
FreeBSD implements what this proposal does, and it works fine.
Iām not sure where this negativity is coming from, Itās fine as a proposal. In any case the community wonāt decide this, the gsoc mentor team will.