> The “OpenWrt One/AP-24.XY” is a Filogic 820-based WiFi 6 router board manufactured by Banana Pi whose software is directly managed by OpenWrt developers with assistance from MediaTek.
> And regardless of how you feel about the default the way they went about it broke things for users
For users using Debian unstable and even there it was apparently fixed/improved after a week.
Debian stable users had no "wild ride" and for the future became the choice to select between the full featured keepassxc version and a minimal variant without non-essential network and IPC features.
Every once in a while I consider making the switch to KeePassXC. I trust KeePassXC but I don't really trust the mobile apps so last time around I looked into NetGuard. It's really nice but it wasn't a good fit for my use case:
> NetGuard will do its best, but it is limited by the fact it must use the Android VPN service. This is the trade-off required to make a firewall which does not require root access. The firewall can only start when Android "allows" it to start, so it will not offer protection during early boot-up (although you can disable your network before rebooting). Also, the Android VPN service needs to be restarted to apply new rules when connectivity has changed or when the screen is being turned on or off. It will, however, be much better than nothing.
I believe that also means you can't use it with Tailscale or similar.
> I believe that also means you can't use it with Tailscale or similar.
You sort of can. It can route over a socks5 proxy to the work profile where you can have a second VPN running. Wouldn't be an easy solution, but it can work
Would be curious to hear if anyone actually did (or attempted) this and have results to share.
I know I have experienced VPN leaks on Android (not the one they publically fixed as it was after). A second layer wouldn't fix that properly but it should make it less likely.
At the OS level LineageOS offers per-app network permissions, which I've used and functions as expected.
One quirk from what I understand of this ticket[1] is if there's a proxy set up via a separate internet allowed app it can bypass the restriction via that app. GrapheneOS' implementation is said to prevent this.
There's RethinkDNS [1](not affiliated to them, just like their software). Sometimes it gets killed on my phone, but otherwise it's a great replacement, adds some much-needed features like proxies and wireguard VPNs on top of a DNS and app level control.
I've been using Blockada for many years but that's a firewall against ads and trackers. No ads inside apps.
Ideally I would use NetGuard to block the apps and Blockada to block ads and trackers for the apps that I allowed to perform network traffic in NetGuard. But Android allows only one active VPN and they can't be chained, so it's a hard choice. Actually it's not so hard: I keep blocking ads and trackers.
Blockada is most likely a DNS level blocker, netguard supports that. Alternatively you can configure it to point the DNS servers at NextDNS if you just want a nice UI to configure block lists (though NextDNS might track you).
NextDNS as a manual DNS server on Android is the adblocking solution I've been using for years. Is there any reason to believe they would track you, any more than any other DNS provider?
I have used GlassWire (not affiliated) for a few years without issues.
It's also rootless so I assume it has the same restrictions, but it's been very helpful with apps like Uber, which I use seldomly, but prefer not to have their notifications shoved in my face every 30 minutes.
It's also helpful for disabling access to most of the bloatware that comes with e.g. Samsung phones and such.
Probably not blocking everything, but I feel like it's at least something.
> Every time you run a `jj` command a snapshot of your local changes is made.
I think that's going to be pretty divisive. For projects where your input is here, your output is there, and that's that I imagine it's fine. Getting people to implement one of the workarounds to avoid junking up the repo feels like a huge ask.
I’ve found most modern codebase have good gitignore discipline, but it’s true that there are codebases that are not. There are also some tools that by default write files to the current directory.
The auto add feature is configurable these days though, so if you don’t like it, you can turn it off.
Auto-adding your changes to existing files sounds like a great feature, auto-adding any random files it finds in the project is a terrible one. I can't imagine why the author decided that was a good idea. Can someone explain the reasoning behind it? I can understand someone wanting it as some point so it makes a certain amount of sense to add as an option, but not as the default. Makes me wonder about what other bad decisions have gone into the project.
I'm a bit more than skeptical. Right now, for a project at work, looking at files in the repo (for testing, etc) I have 294 files untracked and 10 ignored. Using jj all but the ignored files would be committed to the repo and I'd have to something akin to git's filter-branch to clean them out again to avoid that bloat.
I guess I should ask... is that final step made super easy? That is does jj make it easy to completely remove all traces from the repo of those auto-added files (like filter-branch)?
You live with those files showing up as untracked because it was easy and convenient to do so with git.
If git auto-added them from the get go, you would have used a pattern in your personal or project gitignore to skip them, or you would have put them into an ignored tmpdir, or you would keep them on a separate branch if you intend to make them part of the repo. None of these steps would have felt painful or out of place. You see files you don’t intend to include in `jj status` and you’d do whatever is appropriate to exclude them.
I’m with Steve here. I too was skeptical, and it’s turned out to be a complete non-issue.
> and I'd have to something akin to git's filter-branch to clean them out again to avoid that bloat
It’s even more trivial than you might imagine. If you have a commit that added files you don’t want to include you `jj edit` that commit, remove them however is appropriate (rm, mv, add to gitignore, whatever), and… there is no step 3. Later commits are instantaneously and automatically rebased so as to not include those files. Tools like filter-branch are completely unnecessary.
Cool. You've convinced me. A small change in workflow + easy cleanup sounds like it addresses most of my concerns. Though if I were to adopt jj I'd still probably just turn off the feature at first until I saw where I could have used it in practice. I'm going to wait and see for a bit myself. I'm pretty comfortable with git.
The way jj tracks changes isn't a feature you can turn off AFAIK. Maybe you can, but if you can, you shouldn't. This is fundamental to the jj internals and workflow.
As someone who also kept a lot of files in their repo that went untracked, it was a small adjustment. Add to my .gitignore, untrack the files, and done.
You can disable automatically adding untracked files to the repo, but you can't disable it from automatically incorporating changes to tracked files. I believe GP was talking about the former.
You don’t have to convert your team to use jj. So there’s nobody to resist but yourself.
For me, writing temporary output to a gitignored tmp directory has been trivial. And I do exploratory coding in a separate branch. Just because it’s part of the repo doesn’t mean it needs to get pushed.
I think the only thing I really dislike about Fastmail's UI is they've hidden the "Report phishing" and "Report spam" links and they're in two completely different places.
There's a menu bar for the entire email chain, and an "Actions" button for each mail message. Report Spam is only available in the former, and Report Phishing is only available in the latter.
I agree, it's annoying! Maybe someone at Fastmail will see this.
> The “OpenWrt One/AP-24.XY” is a Filogic 820-based WiFi 6 router board manufactured by Banana Pi whose software is directly managed by OpenWrt developers with assistance from MediaTek.