Hacker News new | past | comments | ask | show | jobs | submit login

The problem of FreeBSD adoption is not really for the FreeBSD folks to solve. Fashionable, popular packages have made the explicit decision to avoid BSD support. Over the years I've run into issues with things like Node, Elixir, Visual Studio Code (or any electron app really), Python (Conda) being lax or hostile to supporting anything other than Linux/Mac/Windows.

For config management all of the usual suspects should work and all will be painful to scale in non-FreeBSD specific ways. The Opscode related nightmares finally subsided sometime during the pandemic. Was there a specific package you had trouble with?




VSCode remote not supporting FreeBSD is still so annoying. It's available only as a binary and there's no real, practical reason why it couldn't work beyond Microsoft just not wanting to do so...


Have you tried it in the Linux emulation on FreeBSD? My experience is limited to just my laptop, but significant software builds for Linux (like Chrome) run fine for me. I imagine this could be the case for other things not requiring systemd.


the actual server itself probably works under emulation but the issue is then that when it ssh's in it still uses shell commands to detect the host type, which I can't so easily hack to make it look like Linux without breaking everything else.


The problem isn't in getting a random Linux binary to run. The problem is that you're running a software suite that's designed to not run on FreeBSD.

If memory serves uname(3) should return Linux when you're running a Linux binary, but then you're back to running a hostile program and working around anything that may arise once you have to break out of the Linux userland.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: