I started out with Dokku and it was fine, but ultimately switched to Coolify solely because it has a web UI. Dokku Pro has one as well, but my use case was primarily just for hosting a demo and spinning up instances from GitHub PRs so didn’t feel worth spending money on.
On every service we have ever subscribed I’d say we’ve streamed all that we want to stream within about six months at most. After that there needs to be basically a constant stream of new (good) content or it does not feel worth it.
It's cool Sparkle is still around and offering an alternative for app updates. I remember working with it in Quinn on Mac OS X like 10 or 15 years ago.
I have to say—it's a bit unsettling to me! I released it in 2006; I was a teenager. Obviously, it's evolved since then, and others have taken responsibility for it, but the interface is still the same. I regret that: I didn't know anything about design when I was a teenager. It's not at all graceful. Serves me right, I guess, that I'm now confronted with that poor interface regularly as an adult.
If it’s any consolation, every time I see the Sparkle update UI it reminds me of a much better overall Mac UX and makes me glad some semblance of it still exists. I could certainly critique the design in some ways, but I think it was quite good at providing a consistent upgrade mechanism across the whole ecosystem at the time, and it still has some distinct advantages over the multitude of equivalents that exist today, across MAS and Chrome-style background updates and the kitchen soup of Electron. Even if the interface could be improved, its consistency over so many years is a testament to how well it already solved the problems it addressed. If I could, I’d go back to the de facto standard of Sparkle updates to native Mac apps in a heartbeat.
Interesting. I'm curious what you don't like about the interface in retrospect. I remember being a young shareware dev, seeing that UI and thinking "this is so much better than the bespoke updaters people keep writing". Sparkle ended up being one of the few third party frameworks that I didn't end up stubbornly rolling my own version of, because it just did exactly what I wanted.
Thanks for the kind note. Lots of problems, but my central criticism would be: this is an interface which modally interrupts the user and requests a blocking operation, exactly when the user has indicated intent to perform a task in the app (i.e. when launching it or focusing it).
A better solution in most cases would be to integrate some kind of "update available" affordance into the window chrome, as many interfaces now do. And (with user consent) most apps should simply update themselves when they are not in active use. That is (again, with user consent), desktop apps should simply behave like SaaS apps.
Oh yeah, that’s a very good point. It’s sort of mitigated by the fact that to this day, app launching is a pretty bad experience across the board. It’s just the norm for apps to do annoying things on startup that violate user intent, take focus away, etc. So in a regime where you already have to assume that apps need time to “settle” before you can interact with them (or in fact, before you can reliably interact with anything), modal updates actually don’t make things much worse.
To be honest, I didn't realize it wasn't a native Mac thing until just now. I have always found it to be low friction and just part of the Mac experience, it never occurred to me it was third party.
At least for me, you've certain done it better than almost any other updater.
VirtioFS[0] is making a _huge_ difference on the macOS side. I hated using Docker on macOS for a long time and started testing it as soon as it came out. Had some bad bugs initially and apparently does still have kinks being worked out but I’ve been using it consistently for a few months now and actually forgot all about how terrible the experience used to be. It is such a great improvement.
Baby Buddy[0] just turned five and I’m still hacking away on it! Well mostly reviewing PRs and helping contributors. I get a great deal of enjoyment out of interacting with its users and contributors.
How do you ensure you get enough protein in this situation? Even with meat and eggs as a common source I’d be concerned about getting too much in a single meal and/or not enough overall.
Thanks for sharing. This introduced a few I missed back when I was evaluating alternatives. Nothing I have tried so far fits quite as well as Heroku but Porter looks like it has a chance…
Potentially relevant that the Sentry client is configured in debug mode there. Not sure what the actual impact of that is but maybe it causes additional network traffic to Sentry (outside of crash reports)?
