Please add support for FreeBSD

[yzgyyang]

Can't connect to azure: unreachable or not Linux x86_64 (FreeBSD amd64 )

Since the Electron support is premature on FreeBSD, running vscode in my laptop and connect to my FreeBSD server seems to be a great solution. I'm looking forward to the support on FreeBSD platforms.

[mike-pt]

Would love to have this too, seems like the most work would be around vscode server but considering the deps you list for Linux it seems entirely possible.

[Qint]

The remote server architecture is not supported

---

The server's OS is FreeBSD.

[morganwdavis]

[20:21:58.866] > Running remote connection script
> 
[20:21:58.875] > Unsupported architecture: FreeBSD amd64   
> a993f545-b325-411d-80a3-23ece1e3d1b3##27##
> 
[20:21:58.875] Received install output: a993f545-b325-411d-80a3-23ece1e3d1b3##27##
[20:21:58.875] Unsupported architecture
[20:21:58.875] The remote server architecture is not supported

What would happen if the architecture check was simply ignored/skipped? Would it just work? I can't imagine what kind of esoteric commands being issued over a standard SSH connection would be so architecture-dependent that Linux would work but not FreeBSD. If it's just a matter of using full paths to executables or environment variables, I'm sure we FreeBSD users could create a compatible environment.

[mike-pt]

I actually tried to work around that it does work if u fake it (meaning it passes this check) but it will then try to install things using what would be expected in linux, some would need to be convert to FreeBSD, but more importantly we need vscode-server built for FreeBSD

[morganwdavis]

Yes. I saw that it creates a .vscode-server directory. Client software that silently installs stuff in the user's account is unexpectedly hacky and unfriendly. (I just got a horrible flashback to those ghastly server-side FrontPage web extensions provided by Microsoft 20 years ago!)

I think Microsoft should specify the server environment they require and leave it up to the developer community to create their own compatibility packages for their OS. Then it can be cleanly built and maintained by the best folks who know best, managed using standard package management tools (e.g., pkg under FreeBSD). The user's home directory would then have a set of symlinks or similar mechanism for providing the expected support interfaces.

This can't come soon enough for me. I'm finding that vscode's git features over the Internet to a remote Samba server is excruciatingly slow -- taking a full minute to do a simple commit. (Any tips/workarounds are appreciated!)

[Follpvosten]

more importantly we need vscode-server built for FreeBSD

I'm just guessing, but this shouldn't be too hard, since the server is probably built with TS/JS, right? If the source is available, I'd like to help with this.

[mike-pt]

Thats the issue though the source is not available AFAIK, Microsoft would need to built it and release it, so it can be downloaded on first setup, this is the critical part here.

I didn't find any reference to the source so far.

[mike-pt]

I suppose if someone has the Linux zip we could look into it and see if freebsd Linux emulation works.

[qqkookie]

Same problem. I can contribute to solve this problem. What is main problem that prevents VS Code from supporting FreeBSD? Is it fault of FreeBSD ssh server or Open SSH or VS Code remote SSH extension problem?

[mike-pt]

The main problem is what I described, the vscode server component is not built/distributed for FreeBSD, since its also not open source only Microsoft can do it.

Alternately perhaps we could look into using Linux emulation and then patch the extension side to use the Linux version and do whatever is necessary to get it to install on freebsd, the issue is not ssh or the extension it self (that probably easy to handle).

[davidchisnall]

This is currently the issue blocking me from using VS Code. Please let me know if there's anything I can do to help make this work.

[rob4226]

+1 to please add support for FreeBSD!!! I am sure there are many others who would use it also. It can't be too hard to adapt it to FreeBSD given that it is largely based on the SSH protocol. Thanks!!!

[krowvin]

Agreed, please add FreeBSD support!

[kali-co-kr]

+1 Agreed, please add FreeBSD support!

[n0x32schneider]

+1 Agreed, please add FreeBSD support!

[resnerac03]

Please add FreeBSD support ASAP. I can't work on my favorite text editor coz of this.

[arymkus]

Please add FreeBSD support.

[Follpvosten]

It's great that we have some spiking activity here, the issue might get some attention, but I'm not sure how constructive it is.

I'd like to add something: Please point us to the server source code so we can add FreeBSD support! I'd be willing to help, and I'm sure others would be, too.

[mike-pt]

@Follpvosten +1 I've pointed out the same before, they would need to either release that themselves or open source it so someone can try to build it. AFAIK this is not open sourced (the server code I mean).

[dpetrov]

+1 for FreeBSD support.

[luchoman08]

+1 for FreeBSD support.

[xcdr]

+1, nice to have FreeBSD support.

[RocketSquirrel]

Concur on adding support for FreeBSD. I'm currently relegated to using Eclipse, and while it is sufficient, it's very heavy-handed compared to VSCode.

[ghost]

+1

[tkanjar]

+1

[hansinator]

+1

[guilhermedrud]

+1

[cwlin0416]

+1

[cookys]

+1, it would be great to have FreeBSD support.

[da-tai]

Learning Freebsd, would love this added

[xpader]

I hope fleet can running on freebsd now.

[maisen20]

Really a pity that this is still not supported. So we can't upload via SFTP plugin over sftp but only over ftp and with this unencrypted connection I just don't have a secure feeling.

[han-fastolfe]

+1. I use FreeBSD servers everywhere.

[frank716]

+1

[DoLooP]

+1

[ohmantics]

I tried again a few years later and not even the Remote-SSH plugin can target FreeBSD, which remains closed source. It's odd that the Azure team has gone out of their way to court FreeBSD users for their cloud, sponsoring FreeBSD conferences and such, but the tools folks at Microsoft seem to have their own priorities.

[bobmagicii]

folks at Microsoft seem to have their own priorities.

there is ok, there is another bug on the main repo where all people want is a button to clear the problems pane and its been years.

[davidchisnall]

I tried again a few years later and not even the Remote-SSH plugin can target FreeBSD, which remains closed source. It's odd that the Azure team has gone out of their way to court FreeBSD users for their cloud, sponsoring FreeBSD conferences and such, but the tools folks at Microsoft seem to have their own priorities.

Summarising the discussion from above (not speaking for the maintainers of this project):

There is no strong objection from the VS Code team to supporting FreeBSD but the way that the system is currently designed makes this very difficult due to external dependencies. Currently, VS Code does not provide plugins with an different interface between running things on the host and the remote system. Adding an abstraction layer to do that and porting existing plugins across would be a huge engineering effort. I'd imagine that you'd want to start by providing remote file access proxies and then gradually enlightening plugins to use explicit communication and that's a difficult problem (for example, should I run clangd or some other LSP server locally and require copying the entire source tree across the network to index, or should I run it remotely and require a big program on a system that might be a low-end embedded target?). To avoid this, the remote extension installs VS Code on the remote system and runs it headless, proxing commands, so any plugin that you have on your local system can be installed remotely and work there.

This means that the requirement for the remote extension to work on a given platform is the same as the requirement for VS Code to work on that platform. This brings us to the next set of problems:

VS Code uses Electron. Electron will support any platform that their dependencies run on but they are mostly a wrapper around Chromium and Node.js. Node.js works fine on FreeBSD, Chromium does not. Chromium is a Google project and they support only platforms that Google uses internally or sells products on (Android, iOS, macOS, Windows, desktop Linux, and Fuchsia). To make this worse, the Chromium project has explicitly refused to take patches to support FreeBSD, even with external volunteers maintaining them and providing CI infrastructure, so there is no obvious path to supporting FreeBSD in Chromium.

Neither the Electron team nor the VS Code team is willing to take on the effort of maintaining a fork of Chromium that supports FreeBSD. If you want VS Code to support FreeBSD then you should encourage Google to accept the FreeBSD patches for Chromium. Until they decide to, or an antitrust regulator forces them to, all downstream projects are blocked.

This issue has the second-highest number of thumb-up reactions of any issue on this repo, so it's likely that it would receive some attention if it were unblocked upstream.

[dyeske]

David Chisnall, so you are saying the blocker here is google and chromium. Can you share the patches that need to go upstream? I have maintained over 40 FreeBSD ports in the last 20 years. If we need to pull in some chromium bits and patch then as a vscode dependency we can probably do that. It wouldn't be the first time. Sometimes short solutions are required to get the long term solution completed. Feel free to contact me directly.

[xpader]

Look around files in .vscode-server folder on server, looks like there's no any file exists about chromium binary, only node and js files, base on this, looks like vscode-remote doesn't need Electron's features by itself, may be this is more of an architectural problem?
I didn't view any vscode-remote codes, it's just my humble opinion.

[f-andrey]

Plugin have many hardcoded bash and check on Linux https://github.com/microsoft/vscode/search?q=bin%2Fbash

[mateuszkwiatkowski]

So it seems that linuxulator is good enough to make remote ssh play with FreeBSD.
I prepared a gist with little howto: https://gist.github.com/mateuszkwiatkowski/ce486d692b4cb18afc2c8c68dcfe8602

I have working both remote code editing and terminal. One user reported that terminal doesn't work for him on 13.0 (The terminal process failed to launch: A native exception occurred during launch (forkpty(3) failed.).).

[xpader]

@mateuszkwiatkowski Linuxulator is not full compatible with vscode-remote-ssh, I have tried with Ubuntu 20.04 on FreeBSD 13.0, vscode-remote worked, but some error happened in logs, file monitor notify with inotify not work, so vscode can't detect file change in explorer, some socket options not adapted, process explorer report uv_init error, when close vscode, remote process keep high cpu usage in linuxulator long times, and other problems.
And create linuxulator is not easy.

[mateuszkwiatkowski]

@xpader I don't agreee that linuxulator setup is not easy - its documentation is great and after initial setup it just works. While I'm aware that inotify is not supported by default in linuxulator there's a way to get it working with libinotify-kqueue and linux-libbsd shims. The latter is currently broken on CURRENT but with some community effort it can be fixed and provide even better experience with vscode-remote-ssh. Having that said I'm currently using remote-ssh and it works great for me, vscodes notices file modifications even without inotify.

[BasixKOR]

For those of you who instead want to hack around instead of waiting, you may try code-server instead: https://blog.david-reid.com/vs-code/

[ChocoTonic]

can the instructions be made a little more clear?

[unknowndevQwQ]

For those of you who instead want to hack around instead of waiting, you may try code-server instead: https://blog.david-reid.com/vs-code/

@BasixKOR
Will there be any problems if I use freebsd's npm?
One more thing, the install.sh of coder/code-server now fully supports freebsd(with npm)

[BasixKOR]

Not a support issue for code-server. Ask anywhere else.

[openingnow]

Managed to make VSCodium open-remote-ssh extension work for FreeBSD host.

Follow steps at openingnow/freebsd-vscode-reh

---

The next task would be

1. Make a complete vscode-reh port.
2. Find a workaround to use vscode client.
3. Send patches to the open-remote-ssh extension to fetch the REH port when freebsd system is detected.

[ghost]

I can confirm LSP (at least haskell-language-server) is working. I had some problems with terminal, complaining about missing libutil.so.1, fixed it by upgrading OS from p2 to p3.

[shaojing1779]

Unsupported platform: FreeBSD
940a177439e8: start
exitCode==35==
listeningOn====
osReleaseId==freebsd==
arch====
vscodeArch====
bitness====
tmpDir==/tmp==
platform====
unpackResult====
didLocalDownload==0==
downloadTime====
installTime====
extInstallTime====
serverStartTime====
940a177439e8: end

openbsd & freebsd cant work

[sueszli]

Unfortunately still no support - although it has already been ported: https://www.freshports.org/editors/vscode/

[grahamperrin]

it has already been ported: freshports.org/editors/vscode

If you check all commentary above (including the sixty-something hidden comments), you might find that what's requested here is somewhat different from what's ported.

---

A gentle hint, to other commenters: if your comment was (essentially) no more than a +1, please consider deleting. Allow substantial commentary to be more easily found. Thanks.

[vedranmiletic]

With VS Code 1.86, the support for CentOS 7 is no longer available and the linux_base-c7/linux-c7-* packages, which are the only Linux packages provided in FreeBSD Ports, are no longer helpful to get VS Code remote running. There is no better time than now to consider officially supporting FreeBSD.

[masteradhoc]

@roblourens @chrmarti any plans to support this? +1 from my side

[DavMig]

Hello, +1 for this as FreeBSD is widely used.