This stuff is moving fast, should update automatically. This is kind of standard now. Browsers do it. No reason for harnesses not to do it as well.
Maybe this kind of stuff is standard for some people but I absolutely loathe auto updating software for many reasons
https://www.firefox.com/en-US/firefox/141.0/releasenotes/#:~...
Firefox does not only not prompt me for updates (it only updates if I manually run an update), even if I do update with Firefox running, it does not stop me from continuing to use Firefox without restarting it. All I did was install Firefox from flathub (packaged by Mozilla (a default configuration provided by Mozilla)).
I travel for work, and often have a tech demo, solution, tool, or something to show - or am running a workshop.
I usually do NOT update things right before my trip, as I want to minimize the potential for disruption.
Jokes aside I do the same I tend not to upgrade my Mac, my phone unless I really have to.
The “update” button on the top of my brave install has now turned from green to orange and I’ll likely wait until it goes red
What? Pinning a browser?
First thing it'll want to do after starting is update itself to newest version anyway.
Have you ever actually blocked it due to something in the new version, or is it mostly to control the timing of when it updates?
A human seems less likely to embark upon a path that most humans know leads to something a human is unlikely to want
LLMs produce amazing things, but only one token at a time. Anything beyond that is retrospectively emergent at best
There are contexts where "move fast and break things" can make sense, but usually not when it's other people's workflows that you're breaking.
Just how old do you think a category of software product needs to be before it's reasonable for users to start expecting professionalism from the developers?
Auto-update systems have value but are not a suitable default for professional tools.
Like a simple:
- Dropbox:
- Asked Permissions: File Access [{~/Dropbox, rw}]; App Install/Exec [/Applications/Dropbox.app]; Internet Access [*.dropbox.com]
- They can have additional system defined accessible path inside ~/.cache, ~/.config etc and accessible only via their app package names (if they change their signature - not notarised or shit, user gets a notification and approves it) -> this is the tricky part. I'd rather have an app get a ~/.local/appdata/<app/package name> sort of blanket access for anciliary things and do whatever the shit you want do there.
- optional permissions: []
and so on…
The thing is: the Internet access part one can control with Lulu or other similar apps. But anything else is a user nightmare - next to impossible even for a cli/tweaking/etc comfortable user. And mac's TCC is a royal mess - even their UI part for this is utterly confusing. I think only the Linux world can achieve something sane+easy like this (if it doesn't have that already; though they have not been known for being "easy").
I have achieved a lot of these for harnesses using sandbox-exec (by basically doing: "deny *; then selectively allow") on mac but it was a pain and I can't even think of trying something like that for "normal" apps.