Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A currently maintained fork of SSHFS

github.com

Post reply on HN
Print view View original

111–120 of 144 posts

Re: A currently maintained fork of SSHFS

#111

Post by shric »

kpw94 wrote: post #104
Zambyte wrote: post #62

Earlier quoted context omitted.

My favorite thing about using TRAMP is being able to cd to a directory on a remote system, and then cp a file either from my working directory to my local machine (or another remote!), or from my local machine to the current working directory. Before I started using TRAMP, my flow for this was: SSH to a remote system, locate where I want to copy a file to with cd + ls, kill my SSH session, and then scp or rsync the f…

> kill my SSH session, and then scp or rsync the file over, and then usually SSH back into the system. Naive question: why the need to kill the ssh session? Can't you just open another terminal window or tab (or tmux/screen tab if that's part of your workflow)

Not the GP, but I assume it's just because the ssh swssion is no longer needed -- it was only required to locate the file.

Re: A currently maintained fork of SSHFS

#112

Post by fragmede »

epcoa wrote: post #67
SubiculumCode wrote: post #38

Earlier quoted context omitted.

It does seem like a good fit for the maintainers of openssh. I too had thought it was key linux ssh infrastructure.

No it’s a horrible fit. OpenSSH is focused on a high quality, secure implementation of a rather complex protocol. And OpenSSH is not a core piece of Linux infrastructure any more than say gcc is. These projects serve other, greater ends. A FUSE driver is a bunch of baggage that is poorly suited to be maintained with it.

Given than fusefs provides FUSE support on BSDs, it seems more than "a bunch of baggage", given how useful it is.

Re: A currently maintained fork of SSHFS

#113

Post by fragmede »

mrweasel wrote: post #66
SubiculumCode wrote: post #38

Earlier quoted context omitted.

It does seem like a good fit for the maintainers of openssh. I too had thought it was key linux ssh infrastructure.

I kinda doubt it, SSH already have SFTP and SSHFS is .... quite honestly a tool that has no business existing. It's a neat trick but it's always going to be something that someone bolted on to a solution because they didn't want to deal with a proper file server. Part of the appeal might be that NFS (3 or 4, take your pick) is still the best we've been able to come up with and neither is really that great for basic i…

NFS has too many shortcomings for me to take your answer seriously. SSHFS is a very useful tool in the right places; if it's a hammer and you have a screw, don't use it.

Re: A currently maintained fork of SSHFS

#114

Post by Zambyte »

kpw94 wrote: post #104
Zambyte wrote: post #62

Earlier quoted context omitted.

My favorite thing about using TRAMP is being able to cd to a directory on a remote system, and then cp a file either from my working directory to my local machine (or another remote!), or from my local machine to the current working directory. Before I started using TRAMP, my flow for this was: SSH to a remote system, locate where I want to copy a file to with cd + ls, kill my SSH session, and then scp or rsync the f…

> kill my SSH session, and then scp or rsync the file over, and then usually SSH back into the system. Naive question: why the need to kill the ssh session? Can't you just open another terminal window or tab (or tmux/screen tab if that's part of your workflow)

That's also a way to do it. I prefer TRAMP over both ways though.

Re: A currently maintained fork of SSHFS

#115

Post by wolletd »

shric wrote: post #111
kpw94 wrote: post #104

Earlier quoted context omitted.

> kill my SSH session, and then scp or rsync the file over, and then usually SSH back into the system. Naive question: why the need to kill the ssh session? Can't you just open another terminal window or tab (or tmux/screen tab if that's part of your workflow)

Not the GP, but I assume it's just because the ssh swssion is no longer needed -- it was only required to locate the file.

> and then usually SSH back into the system.

Re: A currently maintained fork of SSHFS

#116

Post by barrkel »

mrweasel wrote: post #66
SubiculumCode wrote: post #38

Earlier quoted context omitted.

It does seem like a good fit for the maintainers of openssh. I too had thought it was key linux ssh infrastructure.

I kinda doubt it, SSH already have SFTP and SSHFS is .... quite honestly a tool that has no business existing. It's a neat trick but it's always going to be something that someone bolted on to a solution because they didn't want to deal with a proper file server. Part of the appeal might be that NFS (3 or 4, take your pick) is still the best we've been able to come up with and neither is really that great for basic i…

sftp doesn’t make it easy to copy files from one place to another on an ad hoc basis while developing, using the shell operations you’ve got to hand.

Re: A currently maintained fork of SSHFS

#117

Post by rzzzt »

kpw94 wrote: post #104
Zambyte wrote: post #62

Earlier quoted context omitted.

My favorite thing about using TRAMP is being able to cd to a directory on a remote system, and then cp a file either from my working directory to my local machine (or another remote!), or from my local machine to the current working directory. Before I started using TRAMP, my flow for this was: SSH to a remote system, locate where I want to copy a file to with cd + ls, kill my SSH session, and then scp or rsync the f…

> kill my SSH session, and then scp or rsync the file over, and then usually SSH back into the system. Naive question: why the need to kill the ssh session? Can't you just open another terminal window or tab (or tmux/screen tab if that's part of your workflow)

I usually type ~ followed by ^Z to suspend the session for a quick scp operation, then resume with "fg".

Re: A currently maintained fork of SSHFS

#118

Post by jlarocco »

zitterbewegung wrote: post #34

If you want something in user land and you don't mind emacs there is TRAMP “Transparent Remote (file) Access, Multiple Protocol”. https://www.gnu.org/software/tramp/ I use it a lot when I am accessing files from my server on my MacBook Pro .

FWIW a lot (most?, all?) of Emacs features work transparently with Tramp, including dired, eshell, and magit.

Re: A currently maintained fork of SSHFS

#119

Post by lmm »

Zambyte wrote: post #62
zitterbewegung wrote: post #34

If you want something in user land and you don't mind emacs there is TRAMP “Transparent Remote (file) Access, Multiple Protocol”. https://www.gnu.org/software/tramp/ I use it a lot when I am accessing files from my server on my MacBook Pro .

My favorite thing about using TRAMP is being able to cd to a directory on a remote system, and then cp a file either from my working directory to my local machine (or another remote!), or from my local machine to the current working directory. Before I started using TRAMP, my flow for this was: SSH to a remote system, locate where I want to copy a file to with cd + ls, kill my SSH session, and then scp or rsync the f…

Couldn't you use zmodem or something?

Re: A currently maintained fork of SSHFS

#120

Post by lmm »

pinusc wrote: post #51
londons_explore wrote: post #10

Earlier quoted context omitted.

I wish github and other code hosters made it easier to "just make a release". Next to the "Download zip" button on github, they should add a "Download built .deb" and "Download built .exe" - and those buttons should work on any fork, branch, PR, etc. And they should add all the necessary build infrastructure to achieve that. It turns out that at scale, build infrastructure is pretty cheap to run, since caching is so…

When making a github release, you can attach whatever file you want, including .exe and .deb. The problem is that building packages is kind of a nightmare, as there's at least one (or, as is the case far too often, many) build system for each programming language. Linux package management is also hard as each distro has its own way of packaging things. And you need a mac to produce macOS Applications... My point is,…

Building packages is easy for most programming languages, it's only very old ones and Python that are bad. While I wouldn't expect GitHub to support every language, and many projects will need customization, them offering a basic pipeline for "standard x" for each of e.g. the top 20 languages (other than the awkward ones) would save a lot of effort over every project reinventing its own pipeline.
Post reply on HN