> I prefer Github's method of "git commit messages don't matter, pull requests do".
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".
> Unfortunately this is broken on the "modern" web as many web pages "helpfully" override the "/" key
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.
I mostly agree, but every now and then there is actually a good reason to override/re-implement them. For example, let us say you are using virtualized components [0], so all available elements have not necessarily been rendered to the DOM (making Control-F useless).
I would still argue in these cases that the site shouldn't override the built-in keybinds. Maybe a custom search field/button, and maybe a custom keybind. But when I press Ctrl+F, I always want the same type of search to be initiated. Otherwise, there is no consistency, and efficiency suffers.
I've had a draft for a similar post lying around for a long time too - this would be about the word "just". It's used too often to undervalue work (just a hobby project, just a webapp...) or be misleading about the complexity of things (just set the dns entry, just solve the halting problem).
The biggest problem I find with Firefox under Sway is that its child windows don’t get sane window types. The most significant place where this goes horribly wrong is notifications: whenever a notification arrives, bam! it’s a full tiling window that steals focus and probably takes half the screen, shuffling everything else around, rather than being marked as a notification window, which would make it float in the requested position, get no decorations, and not get focused. And there’s no good way of targeting them properly to work around this: they’re just Firefox windows with an empty title; but so are download prompts and one or two other things. Still, I decided to favour the notifications (at the cost of download windows and the likes) in my current compromise:
I’ve been thinking I should confirm that there’s a bug report for this at some point, though I can’t imagine it’s unknown. But now I look, I actually can’t find anything about it on Bugzilla (though I can find a complaint about it on Reddit two years ago). There is an unacknowledged report about the About Firefox window not floating (https://bugzilla.mozilla.org/show_bug.cgi?id=1681158), which I expect is connected. Hmm. Oh, and https://bugzilla.mozilla.org/show_bug.cgi?id=1590909 which is fundamentally about this very notification issue, completely unacknowledged after two years. Hmm. Better file something.
Any love for rcm [1]? I settled on this after trying many dotfiles systems - works for me with just the right feature set. I don't often see it mentioned on dotfiles discussions online though.
Huge fan of rcm! I’m in a very similar position - I’ve used many a different dotfile system, and after finally settling on rcm, I couldn’t want more from it.
yep I love rcm. One of the features I use that most of the more barebones solutions don't have is the tag system so I can keep files for different machines in the same dotfile repo.
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.
While most Flatpaks by default aren't all tuned up, you can easily set overrides for them, see `man flatpak-override`. There also exist `Flatseal` which is a GUI for doing so.
AppImage can be used with Firejail.
Firejail use is trivial to setup, we try to keep out of box breakage minimal but still strict, just `sudo apt install firejail && sudo firecfg` + a logout and back in.
Disclosure: I am one of the core Firejail contributors.
Flatpaks aren't docker containers, though. They should be safer. The most glaring hole in most flatpak is X11 access.
There have been some flatpak CVEs in the past, but I wonder what your claim of them not being secure is based on, other than general principles: yes, there could be a bug in the sandbox, but besides that?
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".