Bitdefender updater control
Hi everyone,
Would it be possible to have an updater control feature that gives the user control over what updates are installed and what updates are not.
For example lets say there's a new version of bitdefender but this new version has a bug, to prevent this new version from being installed you would have to disable the updater but then you don't have the definitions updates as well. You can still get the definitions updates when you let the first automatic update run about 5 minutes after boot but then every other update checker also checks for the version updates.
What if instead of having to disable the updater "until next reboot" you have the option to disable only the version update checker but still get the definitions update checker, this way you have the ability to skip a version that contains a bug until that bug is fixed.
Comments
-
i like the idea… voted +1 on this…
another security vendor (can't mention the name, for obvious reasons) has the option to update the program engine and the program virus definitions AND/OR the program… so, you can set each feature to automatic or manual update…
regards….
@camarie @Alexandru_BD any thoughts on this? thanks…
3 -
That sounds familiar, I started that thread in 2012. Feel free to add your vote to it :) :)
All Bitdefender Home Product User Guides: https://www.bitdefender.com/consumer/support/user-guides/ Using BD Antivirus Plus along with Glasswire free.
2 -
Although it looks straightforward on the user interface, the changes on the backend will be complex. Needless to say, the update is a critical component and all changes inside it are treated with extreme care.
Will have to see how team and management feels about this.
2 -
While the concept does sound interesting and as Gjoksi pointed out, some competitors may actually have such an option in place, I'll have to side with camarie on this one, simply because I'm aware of what he said, the changes in the backend would be very challenging to do and there has to be a solid argument to implement this feature on a large scale.
Obviously, before any update is released to the market, the build goes through an extensive testing process which would highlight performance issues for most common configurations. Rolling out updates gradually allows the developers to deploy changes in stages. This approach helps mitigate the risk of widespread issues affecting all users simultaneously. By starting with a small subset of users, developers can monitor for any unexpected bugs or compatibility issues before expanding the update to a larger audience.However, despite rigorous testing, there's always a possibility that unforeseen issues may arise once an update is deployed to a large user base. The developers are always doing their best to limit the impact of any potential problems and the gradual rollout allows them to address issues quickly before they affect a significant portion of users. I think there can also be situations where a bug doesn't manifest for all users.
Another question comes to mind: How would anyone know exactly when to resume the product updates? I'm trying to picture how this would actually work. You get an update prompt, then you decide to wait a bit, but until when? Because if we start with the assumption that the update should not generate any issues in the first place, we consider that if it has been released, it's tested and safe to install and carry on, am I right? On the other hand, I can see how this would work for more tech-savvy users who may probably want to do some research before installing the update..
Anyway, let's see what the developers think about this, I was just thinking out loud.
Premium Security & Bitdefender Endpoint Security Tools user
2 -
"Another question comes to mind: How would anyone know exactly when to resume the product updates? "
Could it not be made possible to revert a version update? When you have a buggy version running having the option to undo the latest version update and revert back to the previous version.
0 -
A revert to a previous update will mean even more changes. Just to say from memory - the version comparison will be confused, driver downgrades should occur etc. And this is from me, which I am not on the update team, so I only can speculate on the outer side of the potential problems.
There is only one place where this is done (with great pains) and this is Safepay runtime for Windows 7, which is based on Chromium and even if it installs the latest version, it needs to downgrade to the latest version supported, which is 109 (even if Chromium now is on 131-132). But that is a particular, contained case (which pains me directly since the same source code has to support basically two forked, different runtimes). But this was a forced decision by Chrome decision to stop Windows 7 support and even that was not easy to contain (basically there is another custom update within update).
Back to this, I do not see this coming without a major rearchitecturing.3
