swalladge
Joined 10 years ago
Joined 10 years ago
This is a bad idea unless it works well for your specific company workflows and you don't care about the future possibility of changing platforms.
Git repos are designed to be self contained, decentralised, and offline-first. If you only care about how things look on github, then the repo will have poor usability outside of github - ie. on your workstation, in your local git tools, on a repo mirror, etc.
Git commits can be a powerful tool for understanding code if the messages are useful. They are immediately accessible through local tools and can quickly add context to a block of code without breaking immersion. But that immersion is broken as soon as you hit a commit messages like "Merge pull request #123" or "fix bugs".
Argh this kind of thing makes me really cross. So many sites seem to feel the need to reimplement things that are already part of most browsers or even in the spec. It's not just overridng default shortcuts, but custom context/rightclick menus, custom 'links' (where clicking them runs javascript code to window.open, instead of being a real link), custom form fields that advertise 'excellent accessibility', where the fields would have been accessible anyway if they didn't decide to reimplement them, disabling text selection, overriding focus styles because the accessible styles 'look ugly' ... the 'modern' web is pain.
Anyway, this wasn't going to be a rant. My point was going to be that consistency is key. Your comment on '"Ctrl+F" instead as I'm too scared to try "/" now' really resonated with me, because I've thought about this before. I've found that a feature or shortcut is only useful if it's consistent. I can't build muscle memory or be confident using a feature if it only works 90% of the time. Or even 99%.
I've tried tridacyl and other vim-style plugins for browsers several times in the past, but always end up uninstalling them in disappointment, because it's not possible to have a consistent experience. 99% of the time it works perfectly, but then there are the handful of sites or browser specific pages (eg. about: or view-source:) where it doesn't work at all, or doesn't work consistently so one must disable it. Then muscle memory totally breaks; you need to learn two sets of keybindings for the same context, and that introduces a hesitation for every keypress, which kills speed and enjoyment.
- https://snapcraft.io/docs/security-sandboxing
- https://docs.flatpak.org/en/latest/sandbox-permissions.html
However, in my (limited) experience, apps that actually do a lot of things have most of the sandbox features disabled anyway (network, disk access, etc.).
Note that AppImage is similar, but contains no sandboxing.
I've taken to running steam and other untrusted software under a separate user account. It's probably not ideal, and it's annoying to switch accounts to use certain software. But at least it may help limit the damage if the software is hacked as everything is contained within the throwaway account.
I'm sure one can do a lot better with selinux/apparmor/firejail, but it would probably take a lot of work to get it set up properly.
It also protects against flaky network connections and accidentally closing the local terminal emulator.