I tried out YNAB, Rocket Money, and Quicken Simplifi.
YNAB was a bit too opinionated and "hands on" for my tastes. Rocket Money seemed to be geared toward the "we'll cancel subscriptions for you" use case and was otherwise not configurable enough.
Quicken Simplifi seems much closer as a spiritual successor to Mint. It's mostly hands-off, though you can set up configurable rules and budgets. And it worked with all of my accounts.
Also a +1 for Simplifi. I switched from YNAB recently. Simplifi maybe isn't as nice looking and feels like the focus is definitely on function (imo), but it seems better for general purpose tracking, and it costs a bit less.
My bank (PNC) was supposedly going to be making it harder for Plaid to connect so I went looking for a different tool. So far it seems like Simplifi will be able to connect multiple times a day for that extreme scrutiny fix! I'd rather banks just play as nice as possible with data aggregators, but I also didn't feel like moving to another bank just to keep using YNAB reliably.
I will give my experience with YNAB full credit for making me realize I need to be tracking expenses carefully, even if I don't need a tool built around YNAB's specific budgeting system.
+1 for Quicken Simplifi. YNAB is more of a methodology, and you pay for the UI. Simplifi is more of tool that lets you look at your money as you see fit.
Lambda has provisioned capacity now. You can just tell it how many to keep warm and it'll keep that many warm (but still cold start additionally as necessary).
Likewise, Linux is also a confusing mess of different parts and nonsensical abstractions when you first approach it. It does take some time to understand how to use it, and in particular how to do effective troubleshooting when things aren't working the way you expect.
But I 100% agree--I think it's the new Linux. In 5-10 years, it'll be the "go to", if not sooner.
It's confusing, but Docker images (and image registries) are also an open standard that Docker implements [1].
A lot of the Kubernetes "cool kids" just run containerd instead of Docker. Docker itself also runs containerd, so when you're using Kubernetes with Docker, Kubernetes has to basically instruct Docker to set up the containers the same way it would if it were just talking to containerd directly. From a technical perspective, you're adding moving parts for no benefit.
If you use containerd in your cluster, you can then use Docker to build and push your images (from your own or a build machine), but pull and run them on your Kubernetes clusters without Docker.
Partly, does't support new iPad pro and only in Brave browser
> At launch, it’ll support these well-known password managers and single sign-on tools: 1Password, Bitwarden, Dashlane, Idaptive, LastPass, and Okta. And when using the Brave browser for iOS, the YubiKey 5Ci can be used as an easier way to log into Twitter, GitHub, 1Password’s web app, and a couple other services.
Yes, and we are already seeing it. The "Home" app on macOS right now is clearly reusing a lot of iOS UI elements. It works, although it's tough to imagine a more native Mac app wouldn't be a better UX.
I think there's probably a case to be made when the app you're building is "mobile first," so you (as the developer) inherently do not want a richer, more feature-filled UI on the desktop. In that case, there's value in having a single UI to maintain and for that UI to be familiar to the user in both places.
You act as if it is some great conspiracy that the Home app is a port from iOS. They outright said that it was a proof of concept for the cross platform framework they are working on.
My apologies if that's how it came across. My intention was to support the parent comment's assertion by pointing to a live example supporting his claim.
Honestly we already discussed this when Marzipan was announced. I guess the news here is just the years they're targeting? Regardless, a lot of the comments here are worried about what the headline implies, which is much more sinister than "a fast and clean way to make an iOS-focused UI app also work on the Mac." And there are already live examples on macOS that actually work fairly well!
I'm an iOS/Mac dev that's released a VPN app on both app stores.
The limiting factor is that the "Network Extension" framework is the way these apps work as VPNs, and currently Mac App Store distribution is the only supported method if you're using that framework (see #8) [1].
Macs are still macs. You can turn off SIP, disable AMFI & entitlement checks, then grant your app whatever entitlements you want and they won’t be verified.
I really really don’t recommend doing that; you’re giving up a lot of security.
A much easier alternative is to have a dev account, then you can just enable the entitlements in your provisioning profile for your dev devices (or personal devices). Most entitlements don’t require any approval for a dev profile.
Sure--I've no doubt there's some ugly workaround process to get around it, but I felt compelled to offer more information because it is usually the case that any Mac App Store app can be distributed outside the App Store relatively easily, except those that use the Network Extension framework.
I wanted to be sure the dev here is backed up that he's not making this up--this is Apple's restriction and not his.
> A much easier alternative is to have a dev account, then you can just enable the entitlements in your provisioning profile for your dev devices (or personal devices). Most entitlements don’t require any approval for a dev profile.
Yes, this is how we test on our own Macs before publishing to the app store. Although iirc those signatures have expiration timestamps, so you'll be re-signing and redistributing on some tedious interval (something like 30-90 days).
- you don't want to be keeping a decryption key secure and in-sync across many (and potentially less-trusted) nodes
- the JWT contains attributes useful to the system (e.g. role, user ID, etc.)
You'll probably still be keeping track of a public key of whatever's signing it (to verify authenticity), but that isn't a secret. And then you can still securely trust
if you don't have a shared data store, or its not fast enough, then you're doing the wrong thing with the wrong tools
> you don't want to be keeping a decryption key secure and in-sync across many (and potentially less-trusted) nodes
keeping shared secrets, which are very high read:write ratio, and change daily or less, should be childs play. If its not, then your security protocols are wrong. Key rotation must be simple and quick if you want your system to scale. When you get to 100 people, you'll be leaking keys weekly.
KMS, Vault and a few others are your friend here. There are off the shelf systems for this.
> the JWT contains attributes useful to the system (e.g. role, user ID, etc.)
having these public can be alright, assuming that you've properly mapped, scrubbed and checked for leakage. However, you shouldn't be reliant on user supplied stuff for this. You simply cannot trust the user.
If you need jwt for caching data, then you have a much bigger architectural problem. The stuff you are storing in JWT needs to be easily and quickly accessed. If its not, you either have a DB or a messaging system issue.
Now, if you are encrypting the whole token, then its less of an issue. But, using it to store anything other than a UUID and a issue time, you are asking for trouble.
I'm speculating but those are at least the two I can think of that aren't explicitly linked to speed equivalency of a basic filesystem.