I dont have a Laptop with a WWAN card, no real need for that.
I guess the OS would detect this connection as limited and could easily pause updates etc.
But what I (and I guess most people) do instead is a hotspot on my phone. So the OS should detect not only WWAN but also specific Wifi network names, to be “restricted”.
This could be done in some hacky way, having specific custom update scripts and doing everything custom, setting up a custom udev rule etc.
I guess this should be implemented into some core network component though, like networkmanager, the possibility to set a network as “restricted” in the GUI or a config file, to make this actually work good.
Automatic updates, especially for firmware, should listen to systemd targets like “battery full”, “AC attached” or “on unrestricted network” and then it would be no problem to have them fully automatically enabled, in the background, with no user needing to click (or most often just ignore) the “ok update” button. There simply is little reason to have updates done manually for maaany users, if you have these checks enabled to avoid bricked hardware or data volume drain.
I am still motivated to do a proof of concept of this, and semi sure it could work ;D
sorry but this makes no sense. An OS should be able to autoupdate without needing a user clicking “okay” like a monkey. Pausing on a metered connection is great, used in GrapheneOS for example.
“just disable autoupdate” is not how automatic updates work. Would you tell for grandma to “just turn off automatic updates”?
I am working on a proof of concept, it works out okay for now, lets see how far I will come.
@vgaetera thanks! I found out in the KDE settings I can also set networks as “metered” which should deal with that part. I will have to check that further. Still, in a “autoupdate setup dialog” which I am currently testing, it would be better to do this more easily.
Idea is:
List all saved networks, pipe to kdialog and allow users to choose multiple networks to be “home networks”
These networks are saved to a list
Systemd service stuff, I dont get them but it should work, only update if the current network is on this list. Set the autoupdate interval too.
Some people love a machine that does everything for them. Some of us hate that approach.
An intermediate stage that suits many (if not most) is to add a reminder when an update is due and allow the user to choose whether to continue the update or not.
I want my own system to do updates on my own schedule and not when it chooses to do so.
I was on a metered connection a short time back, and booted my laptop into windows (which does the updates on its own schedule). The second day of a 30 day period for the data download and windows used 95% of my allowance for data!! That turned me off of automatic updates 100% ever since.
I am sure there are others who have metered connections and if so then they may have experienced similar. Allowing a system to do large data transfers without user acknowledgement and approval is deadly to those with limited data transfer quotas or low bandwidth connections.
Guess I will stick with the other linux using monkey’s who enjoy the freedom of being able to update what and when they choose by clicking ok.I don’t think grandma will mind.
The proposed hacks sound like halfway measures to a Zero Trust Architecture (ZTA) where implicit trust in any single element in complex, interconnected systems is a security risk. For linux, there is NSA’s Zero Trust Architecture from 2020. Appendix B discusses gaps in support identfied in 2020.
Google has done a lot of work on ZTA.
Large enterprises love to manage machines and don’t trust the user component of their complex, interconnected systems. With Microsoft saying they will “end” support of Windows 10 in October, 2025, some big deployments are evaluating ChromeOS, macOS, and linux (MS says “Existing LTSC releases will continue to receive updates beyond that date based on their specific lifecycles.”, but experience has been that such updates have prioritized not breaking existing at the expense of security).
For individuals, the flow of bargain enterprise quality laptops may continue for a while longer (but with higher proportion of well-used machines).
For enterprises I agree. Security is paramount. IT should control when and if updates are applied as well as what software may be installed.
For a home user the freedom of choice is much more preferred since there are still many who have limited bandwidth or limited data plans where the user choice for data transfers may easily supercede any security concerns. A home user does not normally have the restrictions imposed by enterprise IT management.
In the case I mentioned I had a 2G data limit per month and windows downloaded a full system version update at the beginning of that time period and used about 1.8G of my data limit. Not an acceptable situation since that meant the rest of that month I was limited on browsing, linux updates, email, etc.
Had I been allowed to schedule the update I could have done it at the very end of the billing period instead of the beginning of that period.
Are you proposing that autoupdate requires the user’s date of birth to op out?
Surely age is not relevant, its a user’s requirements that mater.
Do they want to have updates to “just work, don’t bother me with the details” or is the user’s requirement “never force a change in environment without explicit consent”?
Yes thats exactly what I mean. Automatic updates need to be smart
only run when system has low load. On GrapheneOS they also use very little processor power
only run on unmetered networks, and opt-in to autorun on specific networks to avoid running on your phone hotspot
only run when batterystate is okay
Intervals need to be settable, but thats not hard. The detection is also possible, and I think querying networkmanagers connected network and comparing it with some given one, is not that hard.
This would then get good GUI integration and distros need to set the used package manager/s.
I think not having autoupdates is simply the lack of doing this in a smart way. Android is easier though, as you simply dont run it on cell data. With laptops and hotspots, this is a bit harder as they are always called differently (“AndroidAP” and that iphone name excluded maybe)
In a local business one could simply enforce automatic updates how they work at least on Debian, Ubuntu, Fedora and Fedora Atomic, and how they could easily be set up using systemd services.
More complex is the Desktop side, as users need to modify the timer, set custom networks to activate the “unmetered” target, maybe enforce AC if their battery sucks, performance is a thing etc.
The same goes with remote work. The “unmetered” tag in networkmanager (I think?) Will help greatly!
