Live data from Hacker News

A currently maintained fork of SSHFS

github.com

71–80 of 144 posts

Re: A currently maintained fork of SSHFS

#72

The main file is a C file which is nearly 5,000 lines long. Impressive. https://github.com/deadbeefsociety/sshfs/blob/main/sshfs.c

This is nothing extraordinary. I don't know why this is a tradition, but this is a very typical situation for C projects.

Compilation used to be slower, and one 5K line file would be noticeably faster than 10 500 line files, not to mention possibly having to build extra header files to connect them together. That would encourage larger files.

Re: A currently maintained fork of SSHFS

#73
post #72

Earlier quoted context omitted.

This is nothing extraordinary. I don't know why this is a tradition, but this is a very typical situation for C projects.

Compilation used to be slower, and one 5K line file would be noticeably faster than 10 500 line files, not to mention possibly having to build extra header files to connect them together. That would encourage larger files.

I'm not sure that's true. Computers used to be smaller, and had a hard time with very large files. Swapping out of limited RAM and so forth. Not fast.

I think long files are solely caused by somebody incapable of software design at any level. They just keep typing and never think about structure or separation of duties or whatever.

I recall the WindowsCE DHCP service was one large file. An enormous busted-ass straightline pile of garbage code that didn't handle most errors. Written by some intern. I re-wrote it for our platform and removed all the issues.

Microsoft of course didn't want my code because, arrogance.

Re: A currently maintained fork of SSHFS

#74
post #36

Earlier quoted context omitted.

Interesting. I haven't tried a speed comparison but I know we sped up the sftp backend recently.

Does the FUSE mount work on OSX?

VFS on MacOS is a minefield. You either need to use a kext (bad option, for many reasons), a network file system (NFS or SMB) and pretend your VFS is a remote server, or create a FileProvider system extension (which cannot actually function as a VFS).

If your workflow relies on a VFS that isn't NFS/SMB then don't use MacOS. fuse-t is kind of clever in that it spins up a TCP server that transpiles NFS requests into FUSE requests, but it comes with a bit of a cost and eats a TCP port. The one benefit is that you can actually mount and use a file system entirely in userspace this way, which you can't do on Linux without sandboxing (fusermount3 is SUID to get around this).

Re: A currently maintained fork of SSHFS

#75

Earlier quoted context omitted.

I love rclone, I'm currently using `rclone mount` to mount a Backblaze B2 bucket to use as backing storage for Jellyfin and it works a treat. There are plenty of dials to tune things like cache size and duration to minimize unnecessary downloads from B2, and with my usage patterns it ends up astoundingly cost effective (although at some point I might move to Hetzner storage boxes for even cheaper storage).

Wasabi might been a good choice for you on that front

Backblaze B2 is $5/TB/month, Hetzner is $4.08/TB/month for 1TB, Wasabi is $6.99/TB/month

Wasabi seems like the most expensive here, with the caveat that Hetzner requires ordering discrete steps of storage rather than the 'pay-as-you-go' model of the other two

Re: A currently maintained fork of SSHFS

#76
post #11

Discovered that you can replace sshfs with rclone. And the project appear to be way more active : https://github.com/rclone/rclone Edit: cf: https://rclone.org/commands/rclone_mount/

rclone kind of drives me nuts not using standard ssh_config

Not just rclone, but it seems that so many things are moving away from using the ssh_config; I have things setup to "just work" for so many hosts with OpenSSH, and having to individually configure a half-dozen programs that build on top of SSH is a pain. Sometimes it's because they use paramiko, other times it's because they want to pass their own configuration options to ssh that mess things up.

Sometimes you can manage to get things to use the ssh_config again (e.g. with xpra you can do "--ssh=ssh" but other times I've not yet figured a workaround.

Re: A currently maintained fork of SSHFS

#77
post #11

Discovered that you can replace sshfs with rclone. And the project appear to be way more active : https://github.com/rclone/rclone Edit: cf: https://rclone.org/commands/rclone_mount/

I'm trying to use rclone, but it seems like it's kind of hard to set up compared to sshfs. Do I really need to go through their 20 question setup script?

You can use connection strings [1] instead of a named remote that you setup ahead of time with the wizard.

    rclone mount :sftp,host=example.com:path/to/dir /tmp/mountpoint
[1]: https://rclone.org/docs/#connection-strings

Re: A currently maintained fork of SSHFS

#78
post #11

Discovered that you can replace sshfs with rclone. And the project appear to be way more active : https://github.com/rclone/rclone Edit: cf: https://rclone.org/commands/rclone_mount/

I'm trying to use rclone, but it seems like it's kind of hard to set up compared to sshfs. Do I really need to go through their 20 question setup script?

You could just edit rclone.conf directly.

Re: A currently maintained fork of SSHFS

#79
post #45

Earlier quoted context omitted.

> I too had thought it [OpenSSH] was key linux ssh infrastructure. As a side note, OpenSSH is quite independent of the Linux ecosystem. It is developed as part of OpenBSD. openssh-portable is provided as a standalone software package that is broadly POSIX-compliant.

>openssh-portable is provided as a standalone software package that is broadly POSIX-compliant. Yes, glad the OpenBSD folks do this. Linux people could learn a lot from OpenBSD Developers (looking directly at Wayland).

I think Wayland is a different beast because unlike SSH, it involves the kernel.

Re: A currently maintained fork of SSHFS

#80
post #76

Earlier quoted context omitted.

rclone kind of drives me nuts not using standard ssh_config

Not just rclone, but it seems that so many things are moving away from using the ssh_config; I have things setup to "just work" for so many hosts with OpenSSH, and having to individually configure a half-dozen programs that build on top of SSH is a pain. Sometimes it's because they use paramiko, other times it's because they want to pass their own configuration options to ssh that mess things up. Sometimes you can ma…

Can you name these programs? I want to add them to my 'painful' list.
Post reply on HN