Tip: Use /var/home instead of /home in VS Code

Just a quick tip for today:

VS Code currently handles symlinks badly. Since /home is a symlink, to the unsuspecting Silverblue user it gives them this buggy behaviour by default.

Navigating to my projects through /var/home fixed all the issues I had. So if your VS Code is not showing you git gutters, or distinguishes between absolute and relative paths, this might be the culprit.

1 Like

Where would /home be a symlink? Are you running on one of the BSDs? Is there a
reason to use /var/home instead of /home for your home directory? If not, you
can just move your homedir to /home to fix that.

This tip was for Fedora Silverblue users: https://docs.fedoraproject.org/en-US/fedora-silverblue/technical-information/

Ah, whoops. Sorry, the Discourse thing doesn’t do a good job at showing what
project a given message is about. That said, I also didn’t know that
Silverblue did that. That’s very weird.

Not if your OS is immutable.

It’s weird regardless, I wonder why the decision was made to move that instead
of just having a separate /home partition simply mounted at /home.

/ being the root filesystem is not mutable if home resides in /home it is immutable then and the user cannot write to their own home dir. Hence the symlink from /var/home since /var is mutable by design.

That’s not necessary, at all. When the kernel mounts /home there, that doesn’t
have to be read-only like the filesystem it’s virtually mounted into. Simply
specify ‘rw’ as one of the mount flags, which is actually the default for most
filesystems.

Hey John,

I am not an expert but I think SB is a little more complicated than just mounting certain filesystems read-only and others read-write. If you run an ls -al / you’ll see that the root directory and most of its contents do actually have write permissions.

Honestly I’m still trying to wrap my head around how exactly it works as well.

When a filesystem is mounted read-only, the permissions are still exposed as
you’d expect. If I had to guess, I think it’d remount as read-write during
updates, then remount back to read-only when done, but I’m not super familiar
with Silverblue. Nothing Silverblue is doing would make it impossible to put
home directories on /home, that’s up to the kernel after you tell it where to
mount them.

As I understand it, the decision to put everything mutable under /var is just that, a design decision. It would not be technically impossible to have /home as a separate read-write file system. See this link for example. It would not have been technically impossible to have /home as a separate read-write file system. Of course it is in some ways simpler to have just one such place to consider.