#60417 closed request (fixed)
noah (run linux binaries on mac)
| Reported by: | axet (Alexey Kuznetsov) | Owned by: | ryandesign (Ryan Carsten Schmidt) |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | ports | Version: | |
| Keywords: | haspatch | Cc: | ryandesign (Ryan Carsten Schmidt) |
| Port: | noah |
Description (last modified by ryandesign (Ryan Carsten Schmidt))
Hello!
Nice port to have 'noah' allows run linux binaries on mac OSX!
https://github.com/linux-noah/noah
brew has is
# brew install linux-noah/noah/noah
Change History (8)
comment:1 Changed 4 years ago by kencu (Ken)
comment:2 Changed 4 years ago by mf2k (Frank Schima)
| Port: | noah added |
|---|---|
| Type: | defect → request |
comment:3 follow-up: 8 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)
| Cc: | ryandesign added |
|---|---|
| Description: | modified (diff) |
| Keywords: | haspatch added |
noah was initially submitted in PR 1744 which was quickly closed and replaced with PR 1745 where most of the previous discussion happened. It looks like it was closed because Ken couldn't get it to work on his machine with High Sierra without crashing, and Perry thought it was too experimental to include a port that we didn't at least think would work reliably on the then-current macOS version.
In my testing on a 2012 MacBook Pro with Retina Display running High Sierra, the software is still unreliable. Half the time, noah crashes at launch with a malloc error, or it launches its emulated bash but then any executable launched by that emulated bash crashes with a segmentation fault. However other times it works fine, at least as far as launching some of the Linux binaries that noahstrap installs, such as ls or uname or which; I haven't sought out any other ELF binaries to test.
Fortunately, it is not our responsibility to fix these crashes. All that we need to do is make it possible for a user to install the software that the developer has provided, and that's what I've done in PR 6986. If the software doesn't work, users can file bug reports with the developers.
The developers have provided Portfiles in their repositories; I used them as the starting point for my Portfiles but made many changes. It is an anti-pattern for projects to host their own Portfiles in their own repositories and ask users to follow our local repository instructions to use them. By adding these Portfiles to our official collection, we can then file PRs with the developers to remove those Portfiles and update their instructions for installing their software with MacPorts. Making it easier for users to install this software should increase the number of users who are available to submit bug reports or pull requests to the developers to get the crashes fixed.
comment:4 Changed 4 years ago by kencu (Ken)
this looked like a cool but unfinished project. there has been zero upstream activity for two years.
A little googling suggests the smart Japanese grad student behind it has been hired by Microsoft to implement something similar on Windows (instead of MacOS, probably).
comment:5 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)
comment:6 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)
| Owner: | set to ryandesign |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
comment:7 Changed 4 years ago by kencu (Ken)
Was I ever right about that --- Windows subsystem for Linux is a major new Redmond project <https://www.techrepublic.com/article/wsl-2-where-is-it-and-where-is-it-going/>
comment:8 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)
Replying to ryandesign:
we can then file PRs with the developers to remove those Portfiles and update their instructions for installing their software with MacPorts.
He's already got a Portfile for it, that he has users install.
I think I recall this software from 2 years ago or so -- there was some discussion about it, IIRC, but in some way or another, it didn't get accepted. I will see if I can find that old discussion from back then.