Hold on any future development

[nhooyr]

I've written a shell script in /bin/sh to automatically and correctly install code-server on any MacOS and Linux system.

It'll be in the main code-server repo.

See coder/code-server#1701

At the moment it does not support installing over ssh but it will soon and the plan is for it to replace and deprecate sshcode as something we'll maintain alongside code-server.

Please let me know your thoughts in this issue.

[Merith-TK]

I dont see the point for this as it will require the user to install code-server or download code-server onto the client machine,
while sshcode works as a functional and prooven tool to achieve this. The only problem with sshcode and code-server is that the way in which code-server is packaged keeps changing, requiring sshcode to be updated to support the new packaging

i see no reason to depreciate sshcode at all,

[nhooyr]

I dont see the point for this as it will require the user to install code-server or download code-server onto the client machine,

It won't require anyone to install code-server locally.

They'd just run the script like so:

# This would install code-server on user@host, forward the port and open it for you.
curl -fL https://get.code-server.sh | sh -s -- user@host

Or if they already had it downloaded somewhere they could just use it and get rid of the curl.

[Merith-TK]

that is more work for a user, who may, depending on local restrictions, not be able to access specific resources. also with the command being longer than needed.

This method would have them be required to contact a remote server every single time to get a script that may be vulnerable to a mitm attack.

and how would configuring code-server via this new shell script even work? sshcode has flags and allow the user to upload their own binary. How would this script implement that?

In the long run, you are making a tool to replace the original, when the original isnt broken nor needs to be replaced. The only thing that needs to be fixed with the original is one component not following a consistent packaging method. which iirc, can be fixed easily by keeping the binary in one spot relative to the extraction point. (see #182 )

Edit:

And you have users who are actively contributing code to the original with the intent of making the tool even better.

Edit2: and there are libraries and add-ons that allow a go binary to auto update itself so ease of updates isn't an actual issue here, just add a check when the program is ran if there if there is an update, and then the user can use a --update flag to update sshcode on the client

[Merith-TK]

i am willing to put work in to make the update flag work in the first place

[nhooyr]

that is more work for a user, who may, depending on local restrictions, not be able to access specific resources. also with the command being longer than needed.

Well you can curl it into a file and then run it wherever if you don't expect to have internet access all the time. Though you need internet access to fetch code-server anyway.

This method would have them be required to contact a remote server every single time to get a script that may be vulnerable to a mitm attack.

You have to fetch code-server every time too. I think the risk of a mitm is blown out of proportion when referring to a install script.

and how would configuring code-server via this new shell script even work? sshcode has flags and allow the user to upload their own binary. How would this script implement that?

We'd have an option that lets you pass in any flags for code-server. or an environment variable. Haven't decided.

Same with uploading your own code-server release.

In the long run, you are making a tool to replace the original, when the original isnt broken nor needs to be replaced. The only thing that needs to be fixed with the original is one component not following a consistent packaging method. which iirc, can be fixed easily by keeping the binary in one spot relative to the extraction point. (see #182 )

Yea sorry about that, I added a symlink in the latest release and replaced the binaries so you can still use code-server at the root of the release.

sshcode isn't broken but it can be significantly improved. I think the script would be a much better UX, easier to maintain and already works across a very wide variety of OSes as it installs packages with the system package manager instead of what sshcode does.

/bin/sh is a much better tool for what we want to do than a Go binary.

Edit2: and there are libraries and add-ons that allow a go binary to auto update itself so ease of updates isn't an actual issue here, just add a check when the program is ran if there if there is an update, and then the user can use a --update flag to update sshcode on the client

To clarify I don't think updating sshcode is a big deal, I just feel no installation at all like you can with a shell script is much nicer.

[Merith-TK]

Well you can curl it into a file and then run it wherever if you don't expect to have internet access all the time. Though you need internet access to fetch code-server anyway.

True on this part, i was a bit heated and didnt think things fully over, however sshcode allows you to upload your own binary. IE: You could have a specific version downloaded or a custom build. In that case you can use that build over the latest official release. meaning if some accident were to happen like the ISP buggering everything up, and you loose internet, you can still access servers locally
This can happen and companies and normal users would have to use local networking over remote resources

Yea sorry about that, I added a symlink in the latest release and replaced the binaries so you can still use code-server at the root of the release.

Very much thanks!

sshcode isn't broken but it can be significantly improved. I think the script would be a much better UX, easier to maintain and already works across a very wide variety of OSes as it installs packages with the system package manager instead of what sshcode does.

Alot of usecases where someone would use code-server that i can think of, they would not have admin access to the remote server, and therefore would be unable to install code-server via the OS package manager. sshcode gets around this by downloading code-server to the remote users home, the 3.X patch uses ~/.sshcode-server to mimic VSCode-Remote with .vscode-server,

/bin/sh is a much better tool for what we want to do than a Go binary.

Really depends on what you are doing. For something like sshcode, i dont see how it could be a simple or a complex sh script as, as far as i know. it doesnt really have all the features one would need for it to work. (I may be wrong in that department, i dont do alot of shell scripting)

To clarify I don't think updating sshcode is a big deal, I just feel no installation at all like you can with a shell script is much nicer.

I would rather have a tool installed on my system, that can update with my package manager like sshcode, over a shell script i have to manually download every time it gets an update or i wish to use it.
And sshcode could contain a v2 build or a v3 targz of code-server as bindata and simply extract and send to the remote if it is unable to acquire a release from the server

[nhooyr]

Alot of usecases where someone would use code-server that i can think of, they would not have admin access to the remote server, and therefore would be unable to install code-server via the OS package manager. sshcode gets around this by downloading code-server to the remote users home, the 3.X patch uses ~/.sshcode-server to mimic VSCode-Remote with .vscode-server,

The script allows you to do this as well with the -s option.

Really depends on what you are doing. For something like sshcode, i dont see how it could be a simple or a complex sh script as, as far as i know. it doesnt really have all the features one would need for it to work. (I may be wrong in that department, i dont do alot of shell scripting)

Shell scripting works really well for this. It's how a lot of people install docker. See

https://github.com/docker/docker-install/blob/master/install.sh

Another cool thing is the --dry-run option so you can see the commands that would be ran to install but not actually run them.

I would rather have a tool installed on my system, that can update with my package manager like sshcode, over a shell script i have to manually download every time it gets an update or i wish to use it.
And sshcode could contain a v2 build or a v3 targz of code-server as bindata and simply extract and send to the remote if it is unable to acquire a release from the server

go get is definitely really nice but idk, curling isn't that bad and we can always add it to the code-server distribution so anywhere you install code-server, you'd have access to the install script via say code-server-install.sh.

It would be untenable to add a release into sshcode as it's nearly 100 MB for every OS/Arch.

[nhooyr]

True on this part, i was a bit heated and didnt think things fully over, however sshcode allows you to upload your own binary. IE: You could have a specific version downloaded or a custom build. In that case you can use that build over the latest official release. meaning if some accident were to happen like the ISP buggering everything up, and you loose internet, you can still access servers locally
This can happen and companies and normal users would have to use local networking over remote resources

The script could totally have an option to use a local release archive, it wouldn't be very difficult.

[nhooyr]

Let's get more opinions in here.

@ammario @coadler @sreya92 @sreya92 @deansheather @kylecarbs

[Merith-TK]

agreed, more opinions do matter.

[coadler]

I don't have a super big opinion but the script makes a lot more sense to me considering there haven't been any commits to this in the past year, and we don't have anyone dedicated to maintaining this. The script would simplify things a lot.

[deansheather]

+1 for script, it'll get updated/fixed more regularly if it's a script

[sreya]

@Merith-TK sshcode was created to provide an easy-to-use, secure way to install/access your code-server instance from a remote server. Though we picked Go to do this originally, it makes for a poor scripting language. Given the updates that @nhooyr has provided, could you elaborate on the objections you still have. I'm failing to understand how Go accomplishes the goal of sshcode better than a bash script.

[Merith-TK]

... considering there haven't been any commits to this in the past year

See the open PR and the msys-support PR. it is being relatively maintained and is doing its job rather well.

+1 for script, it'll get updated/fixed more regularly if it's a script

What makes you say this? why would a script be regularly updated over a program that works just fine with minor tweaks?

Though we picked Go to do this originally, it makes for a poor scripting language.
I'm failing to understand how Go accomplishes the goal of sshcode better than a bash script.

Can you explain why you say this? i havent had any issues with go at all in my time using it
and im failing to see how bash can do what is already done, better.

[sreya]

What makes you say this? why would a script be regularly updated over a program that works just fine with minor tweaks?

More people are proficient in sh/bash than Go. Given that this is a script, it's generally less code to fix a bug in bash than in Go.

Can you explain why you say this? i havent had any issues with go at all in my time using it
and im failing to see how bash can do what is already done, better.

If you look at the code you'll notice that any meaningful work that is being done is calling out to exec.Command. We even embed full bash scripts in our Go code. None of the strengths of Go are being utilized here. While it is not hard to write this in Go it's certainly easier and more appropriate to write this in a shell script.

Also it is hard to beat the workflow of curl https://get-code-server.sh | sh. You either remove the dependency on Go (if you are using go get to update your binary) or you are removing the manual step of downloading a new release to your path every time.

[deansheather]

All sshcode does is run rsync, run ssh, then run rsync again. There's lots of boilerplate involved in executing programs in golang, whereas a shell script would be much smaller and easier to read

[coadler]

sshcode has much less visibility than code-server as well. With a script inside code-server we can get many more eyes on it and ensure it's always up to date.

[ammario]

1. sshcode's lack of commits isn't necessarily bad. It's simple software with a simple scope.
2. The script's UX seems dramatically different than what sshcode does? I don't personally care what language it's written in, but doing sshcode user@server is quite a nice workflow.

I think self-competition is the best way to resolve this problem. sshcode is clearly a succesful workflow, but it's hard to see if the new script will be. I think we should track and measure the usage of both and reconvene after a month of data.

[deansheather]

@ammario From what I gather, you could do:

curl -fL https://get.code-server.sh > sshcode.sh
chmod +x sshcode.sh
./sshcode.sh user@host

[nhooyr]

Yes it'd be as simple as:

# This would install code-server on user@host, forward the port and open it for you.
curl -fsSL https://code-server.dev/install.sh | sh -s -- user@host

[deansheather]

sshcode as it stands right now is just a glorified script written in golang, most of it's functionality is handled by calling out to rsync and ssh, most of the other code is just args handling. The shell version would just do the same steps as the go version but in a more cross-platform fashion.

Since sshcode isn't really maintained anymore anyways I think we should archive this repo when the shell script alternative lands in code-server. If people are still attached to sshcode they could still use it even if it's archived

[nhooyr]

@Merith-TK If you fork I'd be happy to add a link in the README.md to your fork so anyone who still prefers this over the install script can use it.

[Merith-TK]

Alright, that would work, Would need to figure out how to do repo packaging and how to use the build tools you guys have, but i would be alright with that

if that outcome is the final outcome, I would be happy to have some of the team here occasionally reveiwing PRs on it when i cant

[deansheather]

Maybe instead we could just not archive the repo and just keep committing fixes if it breaks. The maintenance work would be minimal, probably only when code-server version changes to update the args/download script.

[Merith-TK]

Yeah, that would work as well.

[deansheather]

It would still be deprecated in favor of the script though, and we wouldn't add any new features. It would only not be archived so we can make sure it still functions.

[Merith-TK]

maybe in the readme have it state there are two methods, the recommended and the alternative?

[Merith-TK]

like for example

### This Tool is no longer officially maintained
This tool is being replaced by a shell script that can use via `curl -fsSL https://code-server.dev/install.sh | sh -s -- user@host` or `curl https://code-server.dev/install.sh > sshcode.sh`

[sshcode](/cdr/sshcode) will still be open to RP's to fix bugs and add features the community wants. And will still be updated to support newer versions of code-server, however there will be no active [Coder](/cdr/] developers working on this project, PR's will still be reviewed and accepted.

This Tool is no longer officially maintained

This tool is being replaced by a shell script that can use via curl -fsSL https://code-server.dev/install.sh | sh -s -- user@host or curl https://code-server.dev/install.sh > sshcode.sh

sshcode will still be open to RP's to fix bugs and add features the community wants. And will still be updated to support newer versions of code-server, however there will be no active [Coder](/cdr/] developers working on this project, PR's will still be reviewed and accepted.

---

just an example of what could be put at the begining of the readme, obviously it would need to be better,

@nhooyr

If you fork I'd be happy to add a link in the README.md to your fork so anyone who still prefers this over the install script can use it.

I do have a fork, a bit out of date with other PR's iirc

[gyzerok]

I would love to read through the whole issue as well as check the shell script to see if it addresses my use-case. Unfortunately can do it during the weekend. So I would kindly ask you to hold on for couple of days if possible 😃

[deansheather]

We're not deleting or archiving the repo at the moment, we're just expressing that this repo will most likely become deprecated soon. You're still free to use sshcode. The script version will accomplish mostly the same things as the go version

[Merith-TK]

You see the script isnt the same as this tool from what i am seeing, the script will outright install code-server onto the remote server, which many people will not like as they need the tool to run without this capability, and what about windows client support? windows does not have an SH binary and not everyone wants to use wsl,

[Merith-TK]

Can we get a update on my previous comment?

[ammario]

We're going to continue holding off feature development here, preferring the script. We will continue to do bugfixes.

[Merith-TK]

Okay, That did not answer my question about windows client support, as it does not have a SH binary, and does not address the issue that it is clunky to use and unless you give it a very specific flag, defaults to attempting to install code-server system wide, rather than just the user,

At the very least, accept the PR to utilize the new V3 format, and then allow the community or others to do things from there, or point to a more maintained fork that is willing to accept PR's with features that users would like to see, such as My Fork

[nhooyr]

Okay, That did not answer my question about windows client support, as it does not have a SH binary, and does not address the issue that it is clunky to use and unless you give it a very specific flag, defaults to attempting to install code-server system wide, rather than just the user,

You normally want to use your package manager to install it, not just for your user. But if you do it's just a flag away. What's clunky about it? It's also much simpler/easier to understand and audit than sshcode and supports more operating systems and they're much easier to add.

At the very least, accept the PR to utilize the new V3 format, and then allow the community or others to do things from there, or point to a more maintained fork that is willing to accept PR's with features that users would like to see, such as My Fork

Windows is an outlier for sure. code-server doesn't even officially support it yet but when it does, I think it's acceptable for a user to have to install windows bash/sh from cygwin/git and we can always add a wrapper around the /bin/sh script in windows batch to install it for you and execute and the /bin/sh script.

I agree we haven't been very responsive on this repository and that's a problem but we're a small company. This is an open source project and we don't want to push it in a direction we do not agree with when we see a better way forward for our users and customers. These things take time.

For now I've added a deprecation notice in the README to this library linking to the code-server install script and I'll try to make some time this week to get the install script on par with sshcode.

[Merith-TK]

You normally want to use your package manager to install it, not just for your user. But if you do it's just a flag away. What's clunky about it? It's also much simpler/easier to understand and audit than sshcode and supports more operating systems and they're much easier to add.

Not really, as most use cases where one would be using said script, they WILL NOT have administrator access to install software on that system.

And while the shell script may be easier to understand for new programmers, it will still be complicated and people coming from normal programming may not even be able to understand shell script, especially as i am unable to even find where the damn script even STARTS, (yes, i am still looking)
And how shell scripts define and handle functions is generally confusing to those who don't make shell script.
IE: if i define a function with function(), i would expect to call said function with function() and not function

Also in my opinion at least, shell script functions should be defined in a top down order of how the function flows, where the beginning is the first line called, and the end is the last function called, In my opinion

Windows is an outlier for sure. code-server doesn't even officially support it yet but when it does,

code-server does not need to support windows in this argument i am making, as windows would be the client machine, not the remote

I think it's acceptable for a user to have to install windows bash/sh from cygwin/git and we can always add a wrapper around the /bin/sh script in windows batch to install it for you and execute and the /bin/sh script.

Please take a look at the utter NIGHTMARE i went through just to get sshcode.exe user@server "/workspace" to work... just look at that chaotic code, and you will see why this, is a terrible idea

For now I've added a deprecation notice in the README to this library linking to the code-server install script and I'll try to make some time this week to get the install script on par with sshcode.

The whole point of this tool was so that a install would not be needed, at all.

[likwid]

SSH does not work with the current script, just in case anyone else spends > 20 minutes like I did trying to get this working.

I don't know if it really matters at this point, but your typo at the very beginning of this entire thread is quite confusing, and with the additional shell snippets that make it seem like ssh is a part of this, when it really isn't.

At the moment it does support installing over ssh but it will soon and the plan is for it to replace and deprecate sshcode as something we'll maintain alongside code-server.

If you only scan and read the first half of this statement, it sure seems like it should work with ssh.

I am sad to see that sshcode won't be maintained, but I look forward to the new developer experience with the script when it is finalized.