5 ms·

> Incidentally, this is also why I never like modifying a working system unless it's absolutely necessary. It's why I find auto-updating apps so infuriating. T

> Incidentally, this is also why I never like modifying a working system unless it's absolutely necessary. It's why I find auto-updating apps so infuriating. The trend is that every app, OS, and driver insists on being self-updating. It's going to be very difficult to maintain a reliable system if you're doing anything complex. Privacy issues aside, that's another reason I never plan to use the continuously self-updating Windows 10.

AznHisoka 10y ago
I hate apps that do 1 job and do it extremely well and it insists I update just so I am on the latest version. It works now stop bugging me. I don't care if you changed the color scheme!
- stephengillie 10y ago
  A benefit to web apps is seamless updating to users. One click loads the updated webpage. They might not even notice their profile pic has changed from square to round!
  - dozzie 10y ago
    ...and then good luck when the application that yesterday worked well today doesn't work at all, because somebody removed a small function critical to your workflow and you can't get it back. Seamless experience!
  - mynewtb 10y ago
    That often is not a benefit for the users though and one of the reasons why I only use 'web apps' for throwaway work.
  - TeMPOraL 10y ago
    Today you reload and see nicer buttons; tomorrow you reload and see them thanking you for the incredible journey you went on together that leaves them with new jobs and $hittons of cash, and you with a search for a new tool.
groby_b 10y ago
On the other hand, chasing after CVEs is also infuriating, but in the opposite direction. auto-update makes it possible to live in an environment where security issues are found by the bucket load every day. There really isn't a good answer either way, but between "breaks occasionally" and "needs a full-time admin, but updates are vetted", I prefer option 1 for my private systems, and option 2 for things that run in production.
- dozzie 10y ago
  This is where supported distributions come in. In Debian or Red Hat you can practically assume that the OS update will not break anything. (There are occasions where it does break something, but I don't remember anything major in a good few years.)
Bartweiss 10y ago
I think this is a serious issue, at least for developers. I've never been burned by a self-updating browser, but anything beyond that seems downright unacceptable. There are just too many fragile, hand-managed dependency chains at work even in good setups.
- greenyoda 10y ago
  "I've never been burned by a self-updating browser..." I develop browser-based software which, after one Chrome update, was rendered unusable by a bug in Chrome. Fortunately, Google pushed out a new version with a fix the next day.
  - Bartweiss 10y ago
    I did suspect that "I've never been burned" just meant I hadn't developed enough for browsers... This also seems like a good reminder that transparent updating only works if your team is good and responsive enough to fix mistakes on the fly. If you're rolling out one update a month, you'd better give people a choice so they can decline when you hand them faulty upgrades.
digi_owl 10y ago
The basic problem there is the mixing of feature changes and security changes in a single stream. So you can't just say you want security fixes only, no new or changed features.
- btilly 10y ago
  The problem with trying to separate them is that often a security fix is put into code that had feature changes, and so you can't get the security fix without the feature changes. Going the other way requires developers to maintain a variety of old versions of their code so they can backport security changes. Which is a lot of work for them for very little extra value.
  - digi_owl 10y ago
    IOW you can't get a developer to do straight maintenance work...
  - dredmorbius 10y ago
    Hence Debian's practice of back-porting security fixes on stable distros. Also applies to Ubuntu, probably Red Hat, though the latter's vastly smaller repos mean vastly greater reliance on third-party sources, and concommitant risks of introducing/changing features when security fixes are wanted, or riding bareback without security updates. There's also the inherent conflict between running current code and fixed code. Debian's legendary conservatism reflects a bias toward the latter, at least on its stable branches. Of course, you're welcome to lead and bleed on testing, unstable, or experimental, if you so choose.

AznHisoka 10y ago

I hate apps that do 1 job and do it extremely well and it insists I update just so I am on the latest version. It works now stop bugging me. I don't care if you changed the color scheme!

stephengillie 10y ago
A benefit to web apps is seamless updating to users. One click loads the updated webpage. They might not even notice their profile pic has changed from square to round!
- dozzie 10y ago
  ...and then good luck when the application that yesterday worked well today doesn't work at all, because somebody removed a small function critical to your workflow and you can't get it back. Seamless experience!
- mynewtb 10y ago
  That often is not a benefit for the users though and one of the reasons why I only use 'web apps' for throwaway work.
- TeMPOraL 10y ago
  Today you reload and see nicer buttons; tomorrow you reload and see them thanking you for the incredible journey you went on together that leaves them with new jobs and $hittons of cash, and you with a search for a new tool.

groby_b 10y ago

On the other hand, chasing after CVEs is also infuriating, but in the opposite direction. auto-update makes it possible to live in an environment where security issues are found by the bucket load every day. There really isn't a good answer either way, but between "breaks occasionally" and "needs a full-time admin, but updates are vetted", I prefer option 1 for my private systems, and option 2 for things that run in production.

dozzie 10y ago
This is where supported distributions come in. In Debian or Red Hat you can practically assume that the OS update will not break anything. (There are occasions where it does break something, but I don't remember anything major in a good few years.)

Bartweiss 10y ago

I think this is a serious issue, at least for developers. I've never been burned by a self-updating browser, but anything beyond that seems downright unacceptable. There are just too many fragile, hand-managed dependency chains at work even in good setups.

greenyoda 10y ago
"I've never been burned by a self-updating browser..." I develop browser-based software which, after one Chrome update, was rendered unusable by a bug in Chrome. Fortunately, Google pushed out a new version with a fix the next day.
- Bartweiss 10y ago
  I did suspect that "I've never been burned" just meant I hadn't developed enough for browsers... This also seems like a good reminder that transparent updating only works if your team is good and responsive enough to fix mistakes on the fly. If you're rolling out one update a month, you'd better give people a choice so they can decline when you hand them faulty upgrades.

digi_owl 10y ago

The basic problem there is the mixing of feature changes and security changes in a single stream. So you can't just say you want security fixes only, no new or changed features.

btilly 10y ago
The problem with trying to separate them is that often a security fix is put into code that had feature changes, and so you can't get the security fix without the feature changes. Going the other way requires developers to maintain a variety of old versions of their code so they can backport security changes. Which is a lot of work for them for very little extra value.
- digi_owl 10y ago
  IOW you can't get a developer to do straight maintenance work...
- dredmorbius 10y ago
  Hence Debian's practice of back-porting security fixes on stable distros. Also applies to Ubuntu, probably Red Hat, though the latter's vastly smaller repos mean vastly greater reliance on third-party sources, and concommitant risks of introducing/changing features when security fixes are wanted, or riding bareback without security updates. There's also the inherent conflict between running current code and fixed code. Debian's legendary conservatism reflects a bias toward the latter, at least on its stable branches. Of course, you're welcome to lead and bleed on testing, unstable, or experimental, if you so choose.