Why the hell does the app check every 5min for updates?
Even once a day seems excessive.
Thy cynic in me sees a pattern of disregard for other people's resources like with electron. Being a good software citizen is also realising that the product is not the main task running on a computer and it's not acceptable to make decisions about other peoples priorities. It feels like every tray daemon and widget assumes they are the main reason the computer is running and load a web view, 3 windows services and scheduled tasks.
Admittedly the App in question is interactive, but the same principle holds.
Categorical imperative hah:
Construct in a way that you accept all tray icons to be constructed like.
It's more insidious than disregard, I expect. I assume it's a beacon masquerading as an update check - monitoring app usage, user locations, and such.
Aside: If your users are in the same time zone you may not want to do checks/updates on startup per se in order to avoid putting all your update load into the same time slice.
> Aside: If your users are in the same time zone you may not want to do checks/updates on startup per se in order to avoid putting all your update load into the same time slice.
This one bite my in the ass with a login used by IRL offices which all wanted to log in at 9:00 at the same time lol
> The problem with the auto-updater we had was that it would prompt the user to update the app as soon as it became available. This resulted in a popup appearing while users were recording the screen, which obviously provided a bad experience as it interrupted the recording the user was making.
The 5 minute bug was introduced while fixing this issue. But it was a bad one: I have so many apps "randomly" popping update notifications up all the time: Skype and Fantastical are the two worst, seemingly every day. The popups interrupt me when working, and _take keyboard focus_ meaning I lose the last half of a sentence, or sometimes even dismiss the dialog before I realise it's appeared.
> the product is not the main task running on a computer and it's not acceptable to make decisions about other peoples priorities
Yes! One thing I loved about early macOS (about OS X Tiger - Snow Leopard days) was that I never saw apps steal focus. On Windows at the time it happened all the time in various ways, but never on Mac. That included when apps started: if you were working in an app and started another but kept working in the first, the second started with the window in the background. It was lovely.
The fact that macOS allows apps to steal focus, with no obvious way to stop it, annoys the hell out of me. That it is apparently new-ish behavior is baffling.
Further: the two biggest productivity boosters macOS could add for me are:
1. Prevent focus stealing (again)
2. Probably more in Sparkle than macOS itself: apps today update constantly. I think it comes from web apps where you can deploy an update and people get it without realising, but updating a desktop app causes an interruption, so it shouldn't happen nearly as often. You end up with multiple apps during the day asking for updates. Apple tried to solve this through the App Store but many apps don't use it and use their own update mechanism, usually Sparkle.
So the Sparkle framework should collect all apps wanting to update and show a single notification (not a popup, a notification) once a day. Clicking it would show all apps that want to update. If you want to read release notes etc, you can there. But a single, centralised, shown via notifications not popups update mechanism for all Sparkle-enabled apps would be a _huge_ boost.
> Yes! One thing I loved about early macOS (about OS X Tiger - Snow Leopard days) was that I never saw apps steal focus. On Windows at the time it happened all the time in various ways, but never on Mac. That included when apps started: if you were working in an app and started another but kept working in the first, the second started with the window in the background. It was lovely.
Good point, when did Mac OS lose that? It's insulting if you know how it used to be.
Another concern, and this could be an Electron issue, why doesn't it download the file to a cache and then skip the download on subsequent checks? I wonder how this behaves on flaky internet access; does it restart the download instead of resuming?
> Why the hell does the app check every 5min for updates?
Part of it is just incompetence. Bootcamp dev is used to coding web apps where the code just gets to the client's machine every time (10 mb single page apps). When they transition to Electron, because it works with the same web tech they memorized, they see nothing wrong with doing these frequent updates.
Part of that is why I don't hate the idea of App Stores on desktop to distribute programs; The store can handle checking for update once per day instead of every app implementing it's own logic.
> Screen Studio is a desktop app. It means we need some auto-updater
No, it doesn't. People used desktop apps perfectly fine before the always-on phone-home era of nearly universal broadband.
What's more troubling though is that this is somehow a story about monitoring cloud costs, and not a story about why your update interval was every five minutes instead of daily; or why it would auto-download instead of politely (no popups!) letting the user know there was an update; or why you failed to reconsider the fundamentals of your design in the face of the first round of negative feedback.
Your users told you they felt harassed and interrupted by your prompts. That's why you were making this change in the first place. That should have told you something.
> People used desktop apps perfectly fine before the always-on phone-home era of nearly universal broadband.
Yes, and people used cars perfectly well before seatbelts. Except the people that died.
If your application is internet connected then you need a good update story so that (if nothing else) you can push out security updates. This is true of everything from embedded firmware to desktop apps.
Let me continue your mangled analogy of the connected car and ask: should a braking profile be auto updated while the car is hurtling down the road in traffic at 60 miles per hour in a torrential downpour? Should the cloud make that determination or the operator?
User expectations have changed in this regard. If you don't auto update users will never update. Updating your computer or apps isn't a thing anyone thinks about anymore.
Don't do it like the OP clearly, and it's really sad that desktops can't provide an experience like mobile where updates are platform managed but you still gotta do it.
I feel like developer / publisher expectations are what changed, not the users’.
The allure of telemetry (even if it’s actually used for telemetry, not for nefarious spying and data collection) is just too much for most developers or publishers to resist. As somebody else said, these 5 minute update “pings” seem less, to me, about updates and more about near-realtime usage monitoring.
> it's really sad that desktops can't provide an experience like mobile where updates are platform managed
What do you mean? There's an App Store for Mac users and there's the Windows Store for Windows users. I bet Linux has some similar offerings as well that I'm not aware of.
The services are there but developers have to jump through a bunch of (compliance) hoops (for good reasons) before they're accepted and it's easier to just let users download a ZIP from your landing page.
I would love if there was an "open" service that any app on the system could use to replace bespoke auto-updaters without having to be distributed via the store. Just like, "hi I'm $app, "run myapp.exe -check" to see if I have an update, and when either the user or the system decides to do the update run myapp.exe -update"
And then it's up to the OS that has more complete information to make decisions on when (i.e. don't check for updates on power saving mode).
That still requires every app to have a bespoke updater. You just pushed the invocation to the OS.
A better solution would be for the system package manager to allow programs to add their own update servers. Assuming the developers package their programs the same way the system does, this allows you to use the exact same update logic.
Most linuxes allow this. Add a third party repository to you sources, and you can update their software with the rest of your system.
Ideally, you would have a more locked down version, where you can restrict the permissions of a given repository; although I'm not aware of anyone that has done that yet
user expectation was never to update regularly. User expectation is a working application to continue function the same way until a change is required by the user.
Users should not have to update, applications should not auto-update unless asked specifically.
An update should be voluntary, not mandatory.
I hate finding a different application each time I open the same application. Particularly if it's a feature change or worse, a whole UI change.
This applies to desktop apps, saas apps, appliances, cars..
> user expectation was never to update regularly. User expectation is a working application to continue function the same way until a change is required by the user.
It does worry me that this may not be true anymore. How many years of the “slowly boiling frog” are necessary, with people growing increasing dependent on software they can’t control running only on others’ computers, before they forget what having locally-controlled software was like? How about young people or those who came to computers late in life who have known nothing different?
I’m increasingly resigned to the fact that the industry will wipe away this past. Old man “yells at cloud”, indeed.
or in other words you normally want to integrate into existing update services, e.g. then package manager on linux. And if it then doesn't get updated e.g. because people don't update their system at all then that's their choice and problem IMHO. Just flag a warning/error once the API to your service changed too much or similar.
You mean no options except the Microsoft/Apple app store. And I think you also can hook into the Microsoft updated without being on the app store but not completely sure. And you can just use a existing auto updater library or similar instead of implementing it yourself ....
Exactly. I am actively developing a desktop app (https://didgets.com/). I have regular releases (every couple of weeks) that contain bug fixes and new features. While it would be nice if every user updated every time the new revision is posted; I don't expect that and other developers shouldn't either.
If it has been about 3 months since the user last updated; it will prompt the user to update to the latest version when the application starts (not some popup when they are in the middle of doing something important).
>> The app checks for the update every 5 minutes or when the user activates the app.
This is why I use Little Snitch, an application firewall that blocks requests like this and gives me some control over which applications are phoning home all the time. There’s no reason a desktop application should check for updates every 5 minutes. Once a month ought to do it without a compelling reason for more. But none of the lessons learned in the article show any attempt to reevaluate the update check frequency.
No. There is enough apps what I start, use and close. Why it should check the update every time it starts?
And this is even more irritating when the update check isn't working for some reason, eg update URI is not available but overall Internet works, now you sit there and wait while the update checker timeouts. Why, why?
Sounds like a decision that could only be made by a company that believes their API will change often (or is for whatever reason worried about 0Ds) and without enough engineering headroom to handle versioning and translation layers correctly. It could greatly simplify a style of development that allows companies to move quickly without paying certain costs.
Screen studio has gone through a period of incredibly rapid development with many new features and improvements, Adam has launched updates every day at times. So I can understand the motivation for at least a daily check.
However those rapid updates also increase the risk of a bug in a release, and so maybe a more regular update check is needed during that time?
Adam is also following the "build in public" marketing strategy, warts and all. It's worked very well, he has had massive growth in sales. The combination of building in public, a product that is "visual" and one that effectively advertises itself, is very clever.
If your background is web apps with CI, thinking you need a 5min update check interval is an easy trap to fall into.
Why? Updates may or may not be to the benefit of the user, who should have a clear say in the time and place when their stuff is updated, nothing is more frustrating to have a job to do and then to sit there waiting for some silly update process to complete only to find out that (1) it doesn't matter to you anyway or (2) that they've borked the update or (3) that critical functionality you relied on has been removed or (4) that the marketing department thought this was a great time to try to upsell you on something.
Mandatory updates should only happen for critical security issues and even those don't need to be fixed on a five minute interval, once a day at most for a check and less frequently is probably fine as well unless the app is absolutely mission critical and people will die. And even then you should probably wonder if your QA is so bad that you need to be able to intervene on a moments notice, better to design your process in such a way that you can alert the user rather than to forcibly upgrade their system, especially if there is a chance that you'll get it wrong (again).
An upgrade is always a burden on the users, so you really don't want to do this too often and even if you are capable of releasing multiple updates per week it would be ridiculous to expect your users to follow that frequency.
In the past if there was an update for software I use I was excited and was curious about all the improvements it would bring. Now when I see some app has an update I have a feeling of dread as I am sure it will be slower, the UI more clumsy and the power features I like will surely be removed.
Especially if you are like Nextcloud client - just killing Explorer if you like so (without asking the user first) and then even rebooting the machine without asking user first.
It's a glorified sync client, why the hell it should behave like that?
I don’t use Little Snitch but the update frequency definitely struck me as insane. I cannot think of any consumer apps that need to check for updates once a day.
This is trying to bring SaaS update frequency to the desktop. As both a SaaS user and SaaS developer, I think this is a big win. Why leave a bug open for a month, fix it the next day if it's serious.
One of our users, who lived in a house, had their internet provider cancel their contract due to enormous traffic generated during a month. It was extremely problematic as there was no other internet provider available around. We decided to take responsibility and offer to cover all the costs related to this situation.
This is how you deal with a situation like this that you’ve caused. Accidents happen, what matters is how you clean up after.
There is, although if you have one wired broadband provider for an address, and that provider isn't willing to overlook a one-time issue, there may not be a lot of options that money can resolve. (The--sometimes--availability of Starlink helps these days but a sole supplier cutting you off doesn't have a universal fix.)
- Why check every 5 minutes? It's not like anyone will die if you wait a day to upgrade.
- Why download it without user confirmation. This is the worst one.
- The timer should not be stopped, or the user is forced to install the last downloaded update before they can install the latest.
It seems unwarranted to go to so much trouble for a screen recorder app, when just checking for an update at startup and prompting the user to go to the website would have been enough.
Why download updates at all without the user knowing? Is prompting before downloading such an awful user experience in comparison? Or, you know, prompt once per day and add a 'remind me in x days/minutes' option?
The whole take-away of this article feels backwards. Instead of going 'hey maybe we should not just download stuff in the background without prompt', the author doubles down and actually proposes to add a way for the server to signal to the client that an update should be forced.
Well, if the user wants the update, downloading in advance is a much better experience, because you only get interrupted once, for a restart that only takes a second or two.
That's in contrast to being interrupted twice (once to download, then again to restart) or a single long interruption (shutting down, then downloading, then restarting).
Of course, it's a different matter if the user doesn't want the update. But we developers don't like to think about that :)
An easier fix could be to just add a toggle so users can decide for themselves if they are fine with the app downloading unprompted or not. (This is just based on the post, the app could very well be behaving that way already but since the post doesn't mention it, I'm assuming it does not).
But also: a check every 5 minutes? I understand what you're saying but the only reason those interruptions are frustrating is because of the high volume of daily updates. This could be solved by just keeping this update-frequency reserved for beta users and maintaining a more sane update-frequency for regular users (now what a sane update-frequency is, is a whole other discussion judging by the comments so far :P)
Now I’m not saying coding is rocket science (because it isn't), but there are certain types of people who are a little (too?) obsessed with thinking of ways their logic can break and covering it with checks and tests… I'm guessing that designers are less likely to be one of those.
I love designers, btw. I think UI/UX is a hugely underrated discipline (see: "dark patterns", designing for safety). But unless you stare at logic all day, the implications of a code change like this might not immediately strike you as a risk.
I agree with you. Bugs happen, that's just the way it is.
But my issues with this aren't really related to code:
* downloading without user 'consent' (in the loosest sense of the word)
* and mainly: a proposed fix being a way the server can force an update on the user.
This whole issue just stems from the unreasonably high update-frequency imposed by the developer. They aren't addressing that and instead conclude that perhaps they can avoid a high bill by building remote code-execution into their app. As opposed to just adding a toggle and letting users decide whether they want updates to be auto downloaded. I would argue that's more of a UI/UX issue than a coding issue.
> Why download updates at all without the user knowing? Is prompting before downloading such an awful user experience in comparison? Or, you know, prompt once per day and add a 'remind me in x days/minutes' option?
Yeah, it's a pain in the neck. If I've got 20 bits of software on my PC and they all update once a month, then most days I'm going to get a random popup asking to update. Just get on and do it please.
That's fair. From the post my impression was that auto-update is forced, so users don't get a say in whether it can download in the background, if that's not the case then disregard that part of my comment.
The article did not mention that as far as I can tell.
>The app checks for the update every 5 minutes or when the user activates the app.
>Normally, when the app detected the update - it downloaded it and stopped the 5 minutes interval until the user installed it and restarted it.
To me this reads as them downloading the update unprompted (as they mention their issue with the previous updater was that it would prompt the users every 5 minutes, which would be solved by just not checking every 5 minutes).
Either way, whatever the bug and its effects are, my gripe is that their conclusion is to add a way for them to remotely force-updates. As opposed to just notifying once or any of the other hundred ways to handle auto-updates that don't involve you remotely forcing an update.
Edit: the founder has confirmed in the comments the app does download without user confirmation, so my original point still stands.
I hate this aspect of modern computing…Time was, you could look over at your firewall, or notice that the local network was running like crap…but Google (and for this post, Comcast/Xfinity) have GOBS of capacity. It’s easy to manage costs when your bandwidth is constrained to a relatively low rate…
That super high speed 1Gb fiber connection? The one that STILL has the 1Tb/Mo cap? You can blow through it in an afternoon with one poorly constrained app (e.g. Torrenting)
Same here. Google has _company ending_ amounts of bandwidth in their datacenters and you can lose everything without knowing it.
I think there is a problem here, but I don't think think that's the right problem. Not having these arbitrary technical limits is a good thing - for instance their service didn't degrade due to an unrelated problem. Regulating cost indirectly via some other metric is a very oblique way of solving the problem
The right solution would be throttling of spending - easy way to set proper limits, good notifications etc. It's possible to set up all these limits but nowhere near as easy as it should be. Also, how easy would it be for Google to send you an email saying "your spend looks a bit different than normal due to this traffic here"!
From personal experience, paying Xfinity an extra $30 or so per month to get the cap taken off was one of the first "upgrades" I made to my internet. Between me pulling node_modules for multiple projects and watching Netflix, I usually blow through the 1TB cap in the first 10 or so days.
I have an unlimited plan (Cox) and they've threatened to terminate me before during a period of high usage. (I was initializing an off-site backup.) Vague language about QoS for other customers in their terms of service, so at their discretion.
I think this post backfired at the writer. While trying to provide transparency over a problem (we all screw up) it uncovered what I think it's a horrible idea.
The issue is not the bug anymore but the update process.
These comments in HN might provide much more insights than the bug itself.
I'm incredibly disappointed in some of the comments here, we are all hackers and makers. We will all have made mistakes at some point, I certainly have - dropped a production DB, taken down an e-commerce site in the middle of Black Friday with a bad push, accidentally DDOSed a massive SAAS accounting package I use and crashed it globally for a couple of hours...
I posted this because it's a good war story, we can all learn from it, and enjoying it at the same time. Laugh along with the OP.
Point is, don't jump to conclusions that someone has made a choice for ulterior purposes, given them the benefit of the doubt. Don't tare someone down because you think they made a silly mistake, we are better than that!
Screen Studio is a solo founder, making an awesome product and releasing updates to it almost daily!
Some of us are software engineers (not just hackers and makers) and feel compelled to point out that if you're writing code which points firehoses of internet traffic at end users of your app, you should be aware of techniques to ensure that code is functioning correctly.
I would have loved to read mention of "testing" or "regression tests" in the author's summary of learnings. "Be careful" and "monitor bandwidth" don't really resonate with me as a sign the author gets it yet.
I have noticed HN threads being increasingly monopolised by cranks obsessing about some "privacy" aspect of the posted story. Recently there was the thread about unlocking Pixel phones. In this case (IMO) excessive freaking out about software checking for updates - a useful and unremarkable behaviour. It's becoming tedious.
>> Normally, when the app detected the update - it downloaded it and stopped the 5 minutes interval until the user installed it and restarted it.
If I'm reading this correctly, the update mechanism stops if there is updated downloaded and waiting. So if user just doesn't install it, it will not get the versions after that?
Seems like whole logic might have more issues, beyond the basic uselessness.
This is bad in multiple ways, as other have said every a 5min check is ludicrous, but the article focuses on losses for the developer in a complete disregard for their users. Some people still have a limited data plan or pay according to usage (people using their mobile phone as a hotspot), in any case, downloading a 250M file without user consent is an abuse.
Is there a reason an app needs to check for updates every 5 minutes vs, say, once a day? That would have made this situation 288 times better, and reduced the processing tax on people’s devices.
When working in the cloud and automating systems, variable pricing scares me. Some providers offer predictable pricing, but the more cloud/variable/auto-scale/serverless you go, the harder it is to predict. Sometimes it's better to fail than to get a huge bill.
If you don't have a billing alarm setup, stop reading HN and add one now.
I understand that for revenue-producing production workloads, stop spending money vs. burn everything down isn't always an obvious decision. But, for for many personal workload cases, I absolutely want to stop spending money above a certain level no questions asked.
Why 5 minutes? Well I ask this question myself as well. I think it was bad and risky idea.
You create MVP and you make 20 decisions like this a day. I probably thought "why not" as it was stopping anyway and I released a few versions a day at times and wanted to get feedback and crash reports quickly.
I did change it now to 3 hours.
Why downloading it without user confirmation?
Well - because this is how Electron auto updater works under the hood (checking for update = downloading it) and it cannot be customized without implementing a lot of the logic by myself. I'll soon modify it and do exactly that, but I was creating MVP, got traction and as solo dev I had to carefully pick things to focus on. Electron auto updater works and is battle tested so I picked it knowing this limitation and suboptimal flow.
---
So I understand a lot of critique you're making and I agree with it. It's just I was making compromises, iterating quickly and making silly mistakes.
Comprehensible, very hard to nail everything on the first try, and a person often has to make tradeoffs.
> this is how Electron auto updater works under the hood (checking for update = downloading it)
Electron auto updater seems too raw, for an app that has a decent size.
> I did change it now to 3 hours.
In my opinion, it is still too frequent. Ideally, the user should be able to set his preference and the app should have a less aggressive default (once a day seem more than enough for most cases).
1 for Alpha/dev/beta testing, whatever, and 1 for "stable".
Allow users the option of being beta testers and getting updates every 3 hours, and if they do not opt in, they're put in the weekly update "stable" group that gets the most reliable and solid but up-to-date version of the app at that time.
What's so big deal in all this 3h vs 24h? It is still downloading it only once anyway and if there is no update the network call it makes is really 300 times more lightweight than opening google.com. I really don't understand this.
It is understandable that you need to iterate quickly, but that should not be an excuse to not spend just 5 minutes to think through the potential scenarios.
Also, you can have a function to query an end point to find latest version available as a string, compare that to a const string inside the build, if they are different then invoke the auto-updater. Simple and light weight.
None. But I also have never costed any of the companies I worked for 8k due to 1 line of code. It was a constructive feedback, but hey take it however you will.
There is a fundamental difference between working in a company and shipping products alone as a solo person.
I did have 3 months of savings left and wanted to pursue my dream of creating a start-up.
I did create a fully working desktop app, a high-quality design for it, a landing page, an entire deployment infrastructure for the website, and uploading new version artifacts. While doing that, I was also taking care of all this marketing (30k unique website visitors a month on avg - analytics is public here: https://plausible.io/screen.studio). And a lot of other shit I don't even remember.
At the same time, you were working at a company where very likely at least one person was working on each of those areas independently, and most of the people did not give a damn if there would be a month delay in some area.
And then, you simply explain to me to compare version strings as if you've discovered a circle. WTF. It is a damn obvious thing, and it, of course, happens. The bug was about a whole different thing, but I'll not even try to explain it as I already did and it didn't prevent you from writing this bs. I wonder if you ever think how would you feel if your co-worker wrote a code review pointing out obvious things you did correctly, not related to the context of the PR at all, and ending it with "Simple and light weight." punchline. Maybe it would give your team an amazing opportunity for a long lunch break to discuss things.
this is really annoying, and this triggered me to write my challenging question.
I really doubt you'd be so "mistakes-free" and "I know it all" if you switched roles with your CTO for a week while all devs will take a week-off. If you write comments to solo founders so confidently, maybe you should consider that or if you're not willing to, to fucking think twice before writing comments next time thinking you're a guru because you nail your full time work.
Looking at the confidence you express your opinion (you actually don't express an opinion, you state your opinion as a fact), I believe there is no slightest thought like "maybe I miss something" or "maybe I'd also do exactly the same thing in this person shoes" and other shit like that.
I admire you for being careful and always thinking through all possible scenarios. On the other hand, I enjoy my life as a founder of a startup that has traction (and all its benefits of it). I'll risk betting that this difference is there precisely because you likely never make such mistakes, and you look at people who do from a perspective of "I know it all, and I'll tell you what you should do." ("Simple and light weight.") (note: it is possible you simply don't dream about founding a start-up which is totally fine. But even then, I believe it is a fundamental mistake to look at people who do create start-ups from the perspective of full-time-work and projecting your perspective on theirs)
--------------
I have no idea why the hell I even discuss with your "compare strings" wisdom. I just wasted 1 hour and half the emotional energy I have for this day and it's 9AM.
> Well - because this is how Electron auto updater works under the hood (checking for update = downloading it) and it cannot be customized without implementing a lot of the logic by myself.
Yay, one more argument against Electron and the likes.
One question is why Android is so "dumb" when it comes to this sort of thing.
I can set a connection as "metered", whatever that means, but no way to set a limit of max throughput (speed/data) whilst on wifi. Android/Google treats WiFi as an unlimited resource, where the OS can consume as much data as possible (so that all the ad tracker networks don't miss out).
Android needs to:
1: Let you disable networking on any app (inc. system) on AOSP
2: Warn you (you know, the 'smart' element of smartphone) when an app consumes an 'unusually' high amount of data - if one app has consumed 200%+ more than any other app maybe, just maybe there should be a notification as such.
This is a sad but important reminder 'you' are treated as a disposable resource on Android. You do not get afforded reasonable control measures over your own device, even on GrapheneOS (which does let you disable networking per app, but not control WiFi data consumption).
Really, similar to "notification channels" there needs to be "data channels" that can be toggled on/off ("tracking", "updates", "resources") etc. And the user should be able to block at the DNS/app level (tracker detection, similar to Firefox would be nice too)
It doesn't seem to be automatically installing the update, presumably as that would disrupt the user by restarting the app. I guess it's staging the update to run on exit or similar. So until the user actually quits the app (or clicks update etc.), it's going to be on the old version, and in this endless redownload loop.
I've experienced broken auto-update functionality throughout my career. The only way to have a great user experience is through the App Store, which allows us to take control of our updates.
This new world of frequent app updates is just a mess, and in most cases, the updates are minor or just marketing spam.
Wow, 1TB of data per user. I hope they weren't on a restricted tariff or you may have also cost them a significant amount in overage fees! If you are going to prompt the user anyway, why not download AFTER they accept the install instead of before?
If the user is on a slow connection, the 250 MB update file could take hours to download. Doing the download first hides that slow process from tbe user.
I suppose the intent there is to not keep the user waiting for those hours while the install takes place? Maybe auto-updating should work same as other apps - install automatically and use the new version on restart?
Not a single mention of rate limiting? This isn't 2008, if you're offering an online service and do not have some form of rate limiting that will trigger when your throughput increases by 3 orders of magnitude, that's on you.
I think the approach for S3 is to have the app call a rate limted API to get the download URL, possibly as a pre-signed URL, possibly with an HTTP redirect. That doesn't help if the client caches that URL and downloads it from S3 directly many times. Alternatively, you could run your own update server, but S3 is so convenient.
There's also a concern that the update is designed to check every five minutes. So a rate limit may not actually get exceeded.
> you could run your own update server, but S3 is so convenient.
IMO if you're providing updates to your users you're distributing code automatically and potentially infecting their computers if anything goes wrong. You should take all proper precautions.
If you're using plain AWS S3 you can't reasonably add a rate limit - probably if you put some Lambda Edge function or Cloudfront in front of it, but that's unnecessary cost and complexity.
Are there any saas tools which help track cloud/saas usage/charges? Or do most people build something homegrown with cloud monitors, pulling billing data from other saas apps, and making data “observability” bi dashboards.
Ex:
- we used to sync 1MM contacts per month to our crm, but this month it’s 2mm
- I created an rds database for testing something, but forgot to turn it off (imaging a “library checkout” feature, where I get permission to create a resource for X time, then alerts if I don’t delete it)
I had something similar happen to me just the other day. One of my websites was running slowly. I had run out of AWS CPU credits.
Did some investigating and finally found the root cause. I had a background backup job that downloaded some resources and then zipped them up and stored them in s3. But I had changed servers, and the final step of the job on the new server was failing. So it just kept downloading resources, failing, and a short while later attempting again.
I put in some new checks to notify me on failures.
There are all sorts of circumstances, see also international travel, when unintentional downloads can get really expensive and it's not reasonable to expect people to police how and when they use data at a micro level. I'd much rather pester people to give permission for things than just download in the background because that's "probably what they want."
I have fixed lines of code that cost many multiples of this in compute cost.
At $previous_company, user-initiated account deletions were only soft deletes, and we were supposed to actually delete data 60 days after the request (in case people regretted their decision). Due to a bug in a SQL query we stopped deleting users (and their associated data) for over six months, racking up over half a million dollars in additional storage cost.
My god the comments are roasting this guy, lighten up people. Like nobody has ever shipped a bug to production before? Thanks for sharing the retro OP.
Would love to know how they resolved the problem on a technical level.
After all, the apps running in the background would still try to download updates every five minutes and disabling/blocking those update requests on the server might cut those installations off from ever auto-updating again.
Additional feedback on HN about checking even less often, getting user consent, and writing regression tests but commentators are being dramatic and insulting about it.
Ah, the good ol' days when the only way to update was inserting a floppy disk into your computer! I'm sure one day we'll return to that model and be as safe as ever.
For comparison, this would cost $3.11 on Cloudflare R2. Data transfer fees on the traditional providers are abysmal, but also kind of a known evil at this point.
...every now and then my brain reminds me that all of LOTR is 3.11mb, The Betrothed (by Manzoni) is 1.2mb and Inferno (by Dante) only 550 kb and then I wonder what the hell we are doing in this century...
memory leak due to custom font added to heads up display
written in Xwindows by major defense contractor. diffed code against mit base, added font free call. $35K paid after two months testing, all for < day's work.
Even once a day seems excessive.
Thy cynic in me sees a pattern of disregard for other people's resources like with electron. Being a good software citizen is also realising that the product is not the main task running on a computer and it's not acceptable to make decisions about other peoples priorities. It feels like every tray daemon and widget assumes they are the main reason the computer is running and load a web view, 3 windows services and scheduled tasks.
Admittedly the App in question is interactive, but the same principle holds.
Categorical imperative hah:
Construct in a way that you accept all tray icons to be constructed like.