dslreports logo
 
    All Forums Hot Topics Gallery
spc
Search similar:


uniqs
867

DigitalXeron
There is a lack of sanity
join:2003-12-17
Hamilton, ON

1 recommendation

DigitalXeron

Member

Users and Update Fatigue

All,

Are users and IT professionals being inundated with updates where they are spending more time updating/restarting than needed? Are devices becoming laden with updaters and similar checks? Has software development started moving too quickly than is healthy? Let's explore:

With software development cycles becoming faster and faster with major versions being released much more often, more and more software these days contains automatic update mechanisms that are deeply integrated and either check for updates periodically or at each start-up.

These updaters often are perceived by users as obstacles and are often resented, with software these days requiring updates on a daily basis, users feel increasingly pressured into turning off updates or simply saying "No" to updates. This has ramifications to software companies issuing updates for security issues where not all devices running that software may be updated.

It is true many software packages can update silently, but often many software developers do not design their software from the core to be modifiable at runtime so updates often require restarts or other things that aren't exactly that graceful. They also notify the user that the software has been updated and so forth in a manner that may interrupt a user's normal flow and act like the update is revolutionary while it may just be a patch for a security issue or a minor bug. This factor combined with the fact that your average computer has many many different components all wanting updates at different times can often come off as burdensome. Even worse is the software that when it needs an update, it directs you to a web site to download manually the new installer to which you need to manually update the software otherwise it harasses you until you comply.

I would like to call the condition where users begin resenting updates "Update Fatigue". It isn't without warrant however with the above in mind where updates are being performed to software with possibly decades-old codebases that were never designed to be updated dynamically. Perhaps it is time for software companies to refactor their software so that updates to critical components can be performed by updating that component then reloading it in the background, similar to how it is possible for Linux systems to be able to update everything but the operating system kernel without a restart.

I have worked with many users who are afflicted by update fatigue where they turn on their computer to see 10 minutes worth of updating being needed by various pieces of software all flashing in the system tray demanding updates. They no longer see the point of updating because it is foisted upon them every day without explanation to why the updates are needed, the vendors and such simply insist "the updates are good for you, you should do them".

In any case, I believe for the current curve and speed of software updates to continue, that update technologies themselves need to involve more than they are now and for updates to be performed more smoothly.

Opinions?

Chubbzie
join:2014-02-11
Greenville, NC
Hitron CDA3
(Software) OpenBSD + pf

1 recommendation

Chubbzie

Member

Add vehicle software updates, consumer electronics, home surveillance systems, farming equipment, etc. to this ever growing list of software updates as well. It has gotten totally out of hand with our technological dependencies.

Lets face the fact that for the most part all consumers are beta testers (possibly even alpha) for most products. When does the update cycle end? When support for said product is EOL I suppose.

goalieskates
Premium Member
join:2004-09-12
land of big

3 recommendations

goalieskates to DigitalXeron

Premium Member

to DigitalXeron
said by DigitalXeron:

It is true many software packages can update silently

If end users are feeling update fatigue, they have only themselves to blame. They gave up the running of their machine to someone/something else via silent update.

My chosen path is to disallow all automatic updates and deal with them only when I have the time to vet them and understand what they're about to change, plus the time to devote to the update process. I feel no fatigue. With the added benefit that I don't waste time at the worst time possible dealing with surprises like moving buttons or changing screens.

It's your computer. You run it, or it runs you.

StuartMW
Premium Member
join:2000-08-06

2 recommendations

StuartMW to DigitalXeron

Premium Member

to DigitalXeron
I was thinking about automatic updaters yesterday and was wondering how many of them collect data (e.g. usage history etc) and "phone that home" while checking for updates. It wouldn't shock me at all if that is happening.

IMO end-users are no longer consumers of software products/services. Instead they are the product with software being the bait to allow vendors to gather information about them. That data is then sold to marketers/salespeople.

Like others I check for updates manually. I routinely disable automatic update services that are installed whether you say you want them or not (Adobe Reader and Java do this).

As to software development cycles you're dead on. I used to be in the business and encountered it first hand. Part of it is due to increased competition and partly due to the ease of making updates available (e.g. via the internet) and installable by end-users. These days one can release barely tested (e.g. alpha) software and release patches as users find issues.

It's a brave new world out there and it doesn't pay to be ignorant of it.
dave
Premium Member
join:2000-05-04
not in ohio

4 recommendations

dave to DigitalXeron

Premium Member

to DigitalXeron
The 'daily update' syndrome is as annoying as hell.

However, I do not want quiet updates, where software updates itself without my permission and I especially do not want software that updates itself without telling me. Why not? Because when something suddenly fails to work today the way it did yesterday (whether due to broken code or simply an intentional change), I will have no idea why. "I didn't change anything".

I don't see the reboot need as particularly onerous (it takes hardly any time at all) and indeed after major software installations, I always reboot immediately in any case: because I want to make sure the system comes up properly, while I still remember what I did to it, not a couple of weeks down the road.

(This is an observation for desktops and laptops; corporate servers are different).

The overall problem is an attitude of ship crap now, fix it in the field later. To some extent, this is user-driven, since people demand a fix/upgrade/feature 'right away'. But not all of it can be blamed on instant-gratification customers.

Plus, of course, too many 3rd-party software vendors think you've bought a PC just to run their pissy little utility program. Splash screen. Entry in start menu, and quickstar bar, and desktop icon. And pointless presence in the system tray.
dave

dave to DigitalXeron

Premium Member

to DigitalXeron
I had update fatigue in the 1970s, before it was cool.

(RSTS/E V6B patch tapes)

StuartMW
Premium Member
join:2000-08-06

StuartMW

Premium Member

Yeah. Real programmers patch the object (binary) code--via front panel switches

. o O (Been there, done that)
Kearnstd
Space Elf
Premium Member
join:2002-01-22
Mullica Hill, NJ

3 recommendations

Kearnstd to DigitalXeron

Premium Member

to DigitalXeron
I think a big issue with updates is the need to restart the whole system for so many of them. I can understand if you are patching the kernel a need to reboot, But many things could they not just restart the service or module?
HELLFIRE
MVM
join:2009-11-25

3 recommendations

HELLFIRE to DigitalXeron

MVM

to DigitalXeron
said by Kearnstd:

I think a big issue with updates is the need to restart the whole system for so many of them. I can understand if you are patching the kernel a need to reboot, But many things could they not just restart the service or module?

Seconded... an OS update needs a reboot I can understand. But anything else? Seriously?

Regards
dave
Premium Member
join:2000-05-04
not in ohio

1 edit

dave to Kearnstd

Premium Member

to Kearnstd
You can't 'restart' a DLL or 'module' - it is mapped into multiple address spaces, and each address space may contain (possibly different) addresses that refer to the DLL.

Your choice with DLLs is this:

1. Arrange so that new processes get the new DLL while existing processes continue to use the old one. This is ok, but for existing processes, it's equivalent to not having done the update yet, so might not be the best choice.

2. Like #1 but restart all processes using the DLL. For more than a few processes total, you might as well reboot the OS, and at least there's no need to write complicated 'restart' logic into application code.

3. Insist that all processes support an indication that they MUST release a certain DLL now. This is impractical except in special cases. It will be application-visible -and- will require some funky methods to undo address fixups.

4. Like #1 but suggest very strongly that users need to restart real soon now.

5. Don't bother installing the new DLL until the restart has been done.

To implement #1, which is what non-rebooters probably want, you need two things: (a) a file system that can allow a given name to refer to a new file while the old file has not yet been expunged from the system. NTFS has some peculiarities in this regard, introduced as far as I can tell for compatibilities with old Windows systems -- the name doesn't go away until the file does. That's not the way I like it, but since it is highly visible to user code, it is too late to change now. There may be some way to replace a file, but it's been a while since I cared about Windows programming in that detail, so I forget (b) a memory management system that can allow a given section to exist in old and new versions.

antdude
Matrix Ant
Premium Member
join:2001-03-25
US

antdude to DigitalXeron

Premium Member

to DigitalXeron
Up(grad/dat)es that require re(start/boot)s are annoying indeed. I only do them when I am ready. Usually, after I make a backup and ready not to use the device for a while.

DigitalXeron
There is a lack of sanity
join:2003-12-17
Hamilton, ON

DigitalXeron to dave

Member

to dave
said by dave:

However, I do not want quiet updates, where software updates itself without my permission and I especially do not want software that updates itself without telling me. Why not? Because when something suddenly fails to work today the way it did yesterday (whether due to broken code or simply an intentional change), I will have no idea why. "I didn't change anything".

Which is why automatic update mechanisms need to be improved, to say, during the update procedure if the system needs to be blocked while the update is applied due to the system being of a poor design to say "Updating $COMPONENT, this update will apply $CHANGES" instead of simply "1 of 10". It will also make the update procedure less of a black box.

Of course users should always have the option to disable automatic updates and be able to review them, but even non-automatic updates are a black box exercise in not knowing what's being updated or why it is needed other than "it is good for you" or "generic security updates". There's practically no communication to the public aside from lengthly technical articles about what updates actually do. Antivirus/antimalware for instance, could have "Installing 50 new signatures, repairing bug to scanning engine that causes stalls" as to illustrate to the user what's going on.
said by dave:

I don't see the reboot need as particularly onerous (it takes hardly any time at all) and indeed after major software installations, I always reboot immediately in any case: because I want to make sure the system comes up properly, while I still remember what I did to it, not a couple of weeks down the road.

I think rebooting is more of a symptom than it is a problem unto itself, it demonstrates systems and programs are monolithic and not designed from the ground up to have individual components updated. Unless it is an operating system kernel, a reboot should be unnecesssary and any programs/etc should simply be reloaded.
said by dave:

5. Don't bother installing the new DLL until the restart has been done.

[..]

To implement #1, which is what non-rebooters probably want, you need two things: (a) a file system that can allow a given name to refer to a new file while the old file has not yet been expunged from the system. NTFS has some peculiarities in this regard, introduced as far as I can tell for compatibilities with old Windows systems -- the name doesn't go away until the file does. That's not the way I like it, but since it is highly visible to user code, it is too late to change now. There may be some way to replace a file, but it's been a while since I cared about Windows programming in that detail, so I forget (b) a memory management system that can allow a given section to exist in old and new versions.

For all intents, Linux does this more or less where the "restart" is the application using that component. The in-memory library remains as-is and the update is performed and commits the new library to disk. This means next time the program is restarted, it'll be restarted with the new library, not requiring a system reboot.

Unix in general has features where as things are more compartmentalized and less monolithic in nature, meaning individual things can be restarted without restarting the system. Even device drivers can be reloaded while the system is in operation.

The problem is in part the design of Windows itself, whereas when a program has a file handle open, that file is essentially "locked" until every program using that file has been exited, this results in the constant need to restart a Windows system to get anywhere with most modifications to executable code because of course, it can be impossible to get every program to 'release' a file that isn't a user file. It's not even a limitation with NTFS as still *nix-based NTFS drivers can still impose the *nix behavior.

Ultimately systems need to be more compartmentalized, this will have a side-effect of improving security as there will be more possible checkpoints to be able to detect an issue from one part of the system trying to exploit another part in another compartment rather than the existing monolithic design that requires everything to be intermingled. Ultimately though, Microsoft won't do this as it'll cause the thousands of bad programmers out there who still demand their programs run as admin to scream bloody murder when their program can't do something to another compartment of the system.
dave
Premium Member
join:2000-05-04
not in ohio

dave

Premium Member


On Windows, the DLL issue is down to pretty much the same reasons that gave you "text file is busy" on Unix. It's not so much that holding a file handle *has* to prevent the file from being replaced (you can open the file in a mode such that that is not true), it's that it makes a reasonable amount of sense in a virtual memory system.

The only admission I'll make here to totally unreasonable Windows behavior is the way that 'remove' does not remove the directory entry until the last handle is closed. That causes ridiculous hoops to need to be jumped through.

(FWIW, I am a Linux programmer whose area of expertise, up until a couple of years back, was interoperability with Windows and every major SMB implementation, every one of which is different. Including the one I wrote).
PX Eliezer1
Premium Member
join:2013-03-10
Zubrowka USA

PX Eliezer1 to DigitalXeron

Premium Member

to DigitalXeron
said by DigitalXeron:

I would like to call the condition where users begin resenting updates "Update Fatigue".

Excellent points, however the term "Update Fatigue" has been used for a long time.
bkjohnson
Premium Member
join:2002-05-22
Birmingham, AL

1 recommendation

bkjohnson to DigitalXeron

Premium Member

to DigitalXeron
Dilbert has had some great comic strips on the subject, such as Wally reporting that he finished no projects because he spent all of his time waiting for his computer to update.