Linux hosting

[lu-zero]

You'd accept contributions to include native kvm support?

[harshdoesdev]

hey, yes would love contributions for this. i was actually looking at rust-vmm/kvm for the Linux backend. the platform stuff is isolated in the shuru-darwin so a similar crate for KVM should be doable. let me know what are your thoughts.

[Gnosnay]

hi i am planing to support windows and macos intel chip.

enable to make it easier to integrate more platform. i created this PR #15 to make architecture clearer

[harshdoesdev]

Hi @Gnosnay, thanks but we don't want to pick these up right now. our main goal is to first make the MacOS (arm) support stable and then start work on the Linux support (actually, we can do it in parallel now). Windows and MacOS Intel chip support isn't planned right now.

[Gnosnay]

@harshdoesdev hi master, I created and manual tested the x86 linux kernel already. you could see it from https://github.com/Gnosnay/shuru/blob/main/kernel/shuru_x86_64_defconfig

I don't want to fork it permanently. do you mind cleaning and refactor the code structure to make it possible that I can contribute macOS x86 version ?

I believe x86 version will be almost the same with arm version

[Gnosnay]

@harshdoesdev besides that I am willing to support windows version also. then the sdk usage will be one problem because it requires shuru-cli installed.

under windows, it is hard to install one cli tool and manipulate it by separated process.

could you please re-consider napi solution again? with this way we could support other platform easily. it might be easy also to support other language like python via https://pyo3.rs

please do consider this. many thanks

[harshdoesdev]

Hi @Gnosnay, I am currently working on Linux support and will raise a PR soon (I might need your help with reviews). The main reason I did not support Node-API initially was that I wanted to focus on the Rust SDK while ensuring the TypeScript SDK was being updated alongside it. A simple subprocess based approach was easier to maintain at that stage. I have been working on a tool that is built on top of the Rust SDK for Shuru, and I have learned a lot from that experience. Based on that, I will either add Node-API support to the TypeScript SDK (while keeping the contract the same so the upgrade path is easier). I understand your frustration regarding PRs and issues not being reviewed in a timely manner. I do have a full-time job and a few other serious projects that I have been working on, but I should have more bandwidth now that the core work on the other project (mentioned earlier) is done. Thanks!

[harshdoesdev]

https://pyo3.rs/ looks promising. will look into it.

[Gnosnay]

Hi @Gnosnay, I am currently working on Linux support and will raise a PR soon (I might need your help with reviews). The main reason I did not support Node-API initially was that I wanted to focus on the Rust SDK while ensuring the TypeScript SDK was being updated alongside it. A simple subprocess based approach was easier to maintain at that stage. I have been working on a tool that is built on top of the Rust SDK for Shuru, and I have learned a lot from that experience. Based on that, I will either add Node-API support to the TypeScript SDK (while keeping the contract the same so the upgrade path is easier). I understand your frustration regarding PRs and issues not being reviewed in a timely manner. I do have a full-time job and a few other serious projects that I have been working on, but I should have more bandwidth now that the core work on the other project (mentioned earlier) is done. Thanks!

looking forward to your excellent work!