That would (just like Git LFS) store full, separate copies of every single version of the large files I manage. I really, really don’t want to go there, nor do I have even a fraction of the hard drive space for that…

That’s what I meant when I wrote “Git submodules can only point to a whole different repository” - they can’t point to a path inside a repository, only to another repository root. That unfortunately renders them useless for me (I’d have to set up in the order of hundreds of small repositories for the sets of shared data I have).

I’m already using Git for source code related versioning, but some use cases involving large binary files with partial updates aren’t well covered by Git (I’ve gone into some detail in my reply to @vvv@programming.dev).

There’s also the lack of svn:externals in Git. Git submodules can only point to a whole different repository as far as I’m aware.

I’m already using Git, thus my experience with Gitea. I am well versed with svndumpfilter and git-svn to extract and migrate individual Subversion repositories to Git.

I’m not only hosting code, but I have several projects involving large binary files with binary changes. Git’s delta compression algorithm for binary files is so-so. Git LFS is just outsourcing the problem. Even cloning with --depth 1 --single-branch gives me abysmal performance compared to Subversion.

So I’m still looking for a nice WebUI to make my life with the Subversion repositories I have easier.

After finding out that tools that are to “bureaucratic” don’t stick with me (bureaucratic as in, I need to fill out forms to create projects/tasks, update them and follow defined workflows), I ended up with Trilium.

It at first looks like a very free-form note taking app (a tree of documents on the left, click and edit away), but it has a lot of extra functionality that lets you construct journals and tasks lists in the document tree (like its Task Manager which is already set up in the Demo notes of a new Trilium install).

Linux Unix since 1979: upon booting, the kernel shall run a single “init” process with unlimited permissions. Said process should be as small and simple as humanly possible and its only duty will be to spawn other, more restricted processes.

Linux since 2010: let’s write an enormous, complex system(d) that does everything from launching processes to maintaining user login sessions to DNS caching to device mounting to running daemons and monitoring daemons. All we need to do is write flawless code with no security issues.

Linux since 2015: We should patch unrelated packages so they send notifications to our humongous system manager whether they’re still running properly. It’s totally fine to make a bridge from a process that accepts data from outside before even logging in and our absolutely secure system manager.

Excuse the cheap systemd trolling, yes, it is actually splitting into several, less-privileged processes, but I do consider the entire design unsound. Not least because it creates a single, large provider of connection points that becomes ever more difficult to replace or create alternatives to (similarly to web standard if only a single browser implementation existed).

I’m on OpenRC, so I can’t say anything about systemd, but I have several SSHFS mounts (non-auto) listed in my fstab:

sshfs#root@192.168.0.123:/random-folder/ /mnt/random-folder fuse noauto,uid=1000,gid=100,allow_other 0 0

Is that similar to what you’ve tried in your fstab? I’d assume replacing noauto with auto should just work, but then again, I haven’t tried it (and rebooting my system right now would be very inconvenient, sorry).

It also might require you to either use password-based login and specify the password or store the SSH keys in the .ssh directory of the user doing the mount (should be root with auto set).

But if you piss him off, he’ll turn right back into Windows95man and send you into DLL-hell.