Isn’t it still the case that, for speeds comparable to an Apple system, x86_64 is still more power/performance efficient than basically any other ARM-based system you can buy?
Bedides, the FreeBSD port of codium works fine and with a few setting changes you can install even the proprietary extensions like the Remote SSH.
There's a few tools I don't use because they don't have a FreeBSD port. I've asked the developers and they were like 'just use the compatibility layer'. But nope, then I'll just pick something else.
Right now I have nothing using the Linux compatibility layer at all which is great.
> (are those different?)
> I'm running FreeBSD because I prefer it over Linux.
Also please remember that entire The Matrix (1999) movie was rendered [1] on FreeBSD machines in Linux Compat Layer because the software used to do that was not natively available on FreeBSD an yet it sill run faster on FreeBSD in Linux Compat Layer then natively on Linux. Let that sink in.
Even today [2] playing Linux games in Linux Compat Layer is faster then natively on Linux - with more FPS and more 'stable' gameplay.
Hope that helps.
I figured it'd be more like how proton provides windows APIs on Linux and applications "just work" as per normal.
I admire your purist approach, but most folks don't have that luxury and just need to make do with what works today for their tooling of choice (or more common, what their employer thrusts upon them.)
It should also be noted that it’s also not native on Linux either as he’s using Wine on both Linux and FreeBSD
BSD is more for purists anyway. Virtualization seems to be a better option than compatibility layers for the odd program that doesn't work natively.
Maybe that it's different for Windows API's on Linux, because by virtualizing Windows, you're still dealing with an unfree OS.
But by supporting options that have real ports, I stimulate those. By giving in to the easy way I will make that more palatable for developers.
And Gnome and KDE have native ports. I really hate the opinionated design of Gnome so I don't use it, but I do use KDE. It does have a lot of cool tweaks by the maintainer to make it work properly.
But yeah my OS should get out of the way but I don't mind investing a little time in getting things working right. That includes picking the right tools. I was looking for a notetaking app and one of them was like 'just use the compatibility layer'. I think it was notesnook. I just picked obsidian instead which has a port. Still not ideal as it's electron but pretty much all these notetaking apps seem to be electron somehow. And I needed compatibility with android too.
If there's something I could really not do without I would consider it but there's nothing like that right now.
For the past few years, my editor of choice has been Visual Studio Code. It’s not perfect and definitely not lightweight, but it strikes a sweet spot between features, extensions, and performance.
Running the proprietary Microsoft build on FreeBSD isn’t really an option but thankfully, the open-source build works just fine. So why write this post at all if VS Code already works?
Because there’s one thing that’s been holding me back from fully daily-driving FreeBSD:
I need an ARM64 machine. Period.
After spending time on Apple’s M1/M2 Macs (coming from a large x86_64 desktop), going back to x86_64 feels like a regression, both in performance and battery life. Unfortunately, there’s currently no FreeBSD-supported (or even Linux, as far as I can tell) ARM64 laptop that truly rivals Apple Silicon. I really hope Framework or someone else changes that in the coming years.
On both Debian (my favorite Linux distro) and macOS, VS Code is a great experience. But most of the projects I work on live elsewhere: embedded Linux systems, OpenWRT devices, and more recently, FreeBSD boxes.
That usually means NFS mounts, SSHFS, or similar setups. And honestly? They’re awful.
My current go-to stack is SvelteKit with a Go backend, and my day job involves a lot of OpenWRT work. As projects grow, editing code over NFS or SSHFS becomes painful especially with many LSPs running. In some cases, it took 5–10 minutes just to open a file. NFS was slightly more tolerable, but after running into countless weird permission issues, I gave up on it entirely.
At that point, it had become a real blocker to my productivity.
Over the last couple of days, I started experimenting with VS Code’s Remote SSH extension. It’s officially supported on most major operating systems but notably not on OpenWRT (musl-based) or FreeBSD.
I tried it on OpenWRT anyway.
And to my surprise… it worked out of the box.
I could connect over SSH, edit files directly on the device, and everything felt smooth. Performance was far better than expected. No hacks. No drama. It honestly felt like magic, working directly on the target device as if it were local.
I’m currently working on a fairly large FreeBSD-centric project, Sylve. Managing it over SSHFS/NFS has been a nightmare due to the sheer number of files and directories.
So, without reading much about compatibility or support, I decided to try Remote SSH on FreeBSD as well.
Predictably, I hit this:
Unsupported platform: FreeBSD
Fair enough.
But before giving up, I did a bit of searching and that’s when I stumbled upon this excellent repository: https://github.com/morganwdavis/vscode-server-freebsd
The setup was almost laughably simple. In fact, I had already done most of it while initially configuring FreeBSD:
service linux enable # This enables the Linuxulator emulation layer
service linux start
pkg install linux_base-rl9 # Install a Linux base system (Rocky 9 in this case)
The Linux-specific PATH does not go into the global environment or .zshrc. Instead, I placed it in a separate file, .bash_linux, in my home directory:
PATH="/compat/linux/usr/local/sbin:/compat/linux/usr/local/bin:/compat/linux/usr/sbin:/compat/linux/usr/bin:/compat/linux/sbin:/compat/linux/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
This file is only sourced when VS Code connects over SSH via the Linuxulator. That’s achieved by explicitly telling sshd to accept the BASH_ENV variable:
sysrc sshd_flags="-o AcceptEnv=BASH_ENV"
And then setting it from the client-side SSH config:
SetEnv BASH_ENV=".bash_linux"
After everything was set up, my final SSH config for the FreeBSD box looked like this (on the macOS client):
Host sylve-code
Hostname 192.168.72.172
SetEnv BASH_ENV=".bash_linux"
User root
Port 22
IdentityFile ~/.ssh/id_ed25519
IdentitiesOnly yes
ServerAliveInterval 60
ServerAliveCountMax 3
RemoteCommand /compat/linux/bin/bash
I was honestly skeptical. I expected half my extensions to break, language servers to crash, or performance to be mediocre at best.
None of that happened.
Every extension I rely on worked flawlessly except Rollup, which doesn’t ship FreeBSD binaries. But even that wasn’t a blocker: it does have a WASM build, so I simply overrode the dependency in npm:
{
"overrides": {
"rollup": "npm:@rollup/wasm-node@^4.30.1"
}
}
Problem solved.
The result? A fast, smooth, fully-featured remote development experience on FreeBSD running Linux binaries transparently via the Linuxulator.
It genuinely feels like magic.
More importantly, it’s a testament to how stable the Linux ABI itself is and how well FreeBSD’s Linuxulator implements it. This setup completely changed how I work with FreeBSD, and it finally removed one of the biggest friction points in my workflow.
I’m seriously impressed and genuinely excited to see how far this can go. This is one of those rare setups that feels fragile on paper but in practice, it just works.