This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new Linux.com!

Linux.com

Feature: Commentary

The dangers of automatic updates

By Bruce Byfield on September 14, 2007 (9:00:00 PM)

Share    Print    Comments   

When I started using GNU/Linux eight years ago, I was dumbfounded to encounter Debian users who started their day by upgrading their entire system. Yet now, with the updaters that sit in the notification trays of recent GNOME and KDE-based distributions, I realize that these daily upgraders were not daredevils, but pioneers in the idea that all upgrades are desirable. Never mind that this idea is an nuisance and an unwarranted assumption -- let alone that constant upgrades are unsuitable to many styles of computing and contrary to responsible system maintenance.

I don't know about anyone else, but my usual reaction to an updater is irritation. Admittedly, GNU/Linux updaters are not as bad as Windows'. In that operating system, a popup notification about updates seems to ambush you every 30 seconds, and you are constantly warned that your system is at risk if you turn off automatic updates. So far, updaters in GNU/Linux are more restrained, distracting you with a popup about the number of available updates only when you login, or placing an icon in the system tray. Moreover, only one updater exists for the whole system in GNU/Linux, while in Windows Vista you can have as many as three or four. And at least a GNU/Linux updater can be turned off.

However, the tendency toward nagware is still there, distracting you from whatever you are doing with a notice that you probably don't care about at the moment. Give me a log file that I can view at my leisure any day.

But updaters are more than just a nuisance. They're an active hazard. Presumably the assumption behind updaters is that the newest version of a software package is more secure and less buggy. But that, as anyone who explores his system soon finds out, is an unwarranted assumption.

Conflicts between programs, unresolved dependencies, and broken systems all await those who avail themselves of over-ambitious upgrades. The mailing lists of just about every distribution are full of the lamentations of the reckless who have trashed their systems through unwary upgrades. The truth is, except for security updates and fixes for specific problems, the average desktop user is likely to have fewer difficulties with an "if it ain't broke, don't fix it" philosophy.

Yet updaters make their functions all too easy to use carelessly. Right-click on any of them, and you have an option to install all updates without looking at them. They also give you the option to view and select updates, but, in Fedora 7, you are hardly better off than updating blindly, because all you get is a single sentence description of the package. From that description -- or possibly the package name -- you might be able to tell how important a particular piece of software is to the smooth running of your system. But what you can't tell is what changes have been made in the update, and whether the update is useful to you.

The Debian updater at least gives you a list of changes in an update. Yet even this list is concealed until you click the Show Details button. In all the updaters, the design encourages blind acceptance of all updates. Contrary to the assumption that updating is responsible, they encourage updating in the most irresponsible way possible.

This behavior is bad enough when you stick to the standard repositories. If you stray further afield, updaters can potentially create even greater problems. For instance, add the experimental repository to Debian, and, the next time you log in, you may be informed of dozens or hundreds of new updates of questionable quality. There is no mechanism to exclude individual repositories or packages from updaters, though most of the time, users go to nonstandard repositories for specific packages, looking for solutions to specific problems. They have no interest in most of the repositories' contents, which were never intended for everyday use anyway. Yet, with an updater, one careless choice made after adding such repositories, and suddenly you are invited to gamble with your system.

Of course, you might say that users should know better than to be so careless. But the fact is that it's easy to make mistakes when you are distracted or careless (and if you don't believe that, then you are a prime candidate for disaster; the point of making things idiotproof is that we can all be idiots sometimes).

Anyway, many desktop users don't know better. Why should they, when the automatic installation of the updater and its menu items encourage them to think that adding every new update to their system is standard procedure? They don't know enough to read the bug lists for every package on their system, and most of them wouldn't take the time to do so anyway.

A list of updates is useful for system maintenance. Yet it needs to separate out security fixes from bug repairs and added functionality, and it needs to give enough information for users -- especially new ones -- to make informed choices. Otherwise, you may as well be in Windows, where users are discouraged from a hands-on approach to their systems.

Bruce Byfield is a computer journalist who writes regularly for Linux.com.

Share    Print    Comments   

Comments

on The dangers of automatic updates

Note: Comments are owned by the poster. We are not responsible for their content.

The dangers of automatic updates

Posted by: Anonymous [ip: 216.15.33.226] on September 14, 2007 09:28 PM
In the opensource world it seems that since apps are perpetually in "beta" the inclination to constantly update is very strong. Also thanks to the rapid development of OSS it is usually necessary to update sooner to get the newer features or resolve annoying bugs/insecurities. Don't modern package mgrs account for these lib conflicts?

#

Different distros for different needs

Posted by: Anonymous [ip: 62.121.101.201] on September 17, 2007 09:43 AM
The feeling you have suggests that you are probably using the wrong distribution for your needs. To avoid the "beta software" feeling there are two things you should aim for; choose a stable branch and choose an old release. By stable branch, I mean that you should choose RedHat Enterprise Linux or CentOS rather than Fedora. You should choose Debian Stable rather than testing. If you are choosing Ubuntu you just have to check that you have a long term maintainance version.

When it comes to lifecycle then you should have a look at RedHat's lifecycle explaination https://www.redhat.com/security/updates/errata/ ; this is very similar on other distributions, but perhaps not as formalised. By choosing a product which is older than either 3 or 3.5 years you will get a vastly reduced package update rate. However, note that since you have chosen an officially maintained distribution, you don't have to do version upgrades to get bug fixes. The important ones will be back ported. At the point where you are using RHEL from four years ago, you will find that most updates are sufficiently critical that it is worth automatically updating them anyway.

Finally, you should note that the definition of "important ones" is something you might like to influence rather than just accept. At that point you will want a support contract of some kind. When you have one of these with RedHat, for example, they will do bug fixes specifically according to problems which are affecting your business.

#

The dangers of automatic updates

Posted by: Anonymous [ip: 67.151.116.54] on September 14, 2007 10:09 PM
One size doesn't fit all. On servers, for example, one might favor stability over all else. Uptime is key, so I don't want to change ANYTHING if I don't have to. On desktops, though, I'm willing to accept more risk in order to get new features. in addition, since desktop users run a variety of network-facing programs in a fairly ad hoc way (e.g. browsers), they are arguably in greater need of security patches, since such programs are frequently the target of hackers.



I think the responsibility for pushing only "stable" updates lies with the distro vendor. Having different repositories for security updates is helpful, too, so a user can restrict updates to those if they wish.

#

The dangers of automatic updates

Posted by: Anonymous [ip: 82.245.45.22] on September 14, 2007 10:30 PM
"There is no mechanism to exclude individual repositories or packages from updaters". With debian/ubuntu, you can pin packages (in /etc/apt) and I'm quite sure there's someting like this in redhat too (kernel aren't upgraded by default, so there must be qan option somewhere to do this)

#

Excluding updates

Posted by: Anonymous [ip: 75.34.17.86] on September 15, 2007 05:35 AM
gentoo (and derivatives) let you mask packages greater than the current version too.

#

Excluding packages on RHEL / Fedora

Posted by: Anonymous [ip: 62.121.101.201] on September 17, 2007 09:55 AM
if you include a line like

includepkgs=sylpheed* compface* ....

in your /etc/yum.repos.d/XXXX.repo file then only those packages will be updated. You can use this to specifically select those packages which you want to be updated. You might use this, for example, to only update internet facing daemons. However, if you do this, be sure to update also libraries and other software which can be called from them. Using SELinux correctly will let you be sure that you have the correct partitioning of the system since you can limit the daemons to only using files belonging to the updated packages.

#

well, not that much hassle

Posted by: Michael Shigorin on September 14, 2007 10:31 PM
Guess those Debian folks might even track unstable which would be perfectly OK for them but a disaster for someone e.g. sitting on Rawhide.

Basically, any sane default repositories configuration would only put _security updates_ one as something where new package builds can appear. And then user would be actually updating what has to, not just everything around.

Your concerns over not representing some sort of a changelog summary are valid to me, but I'm afraid average Joe is better of by either trusting that distro maintainers know what they're doing and why did they go out on a limb and build an updated package for a stable release -- or changing the distro until there's one that can be settled on. Just as well your proposals at separating security updates/errata and version updates are perfectly valid as well -- the latter's long known as "backports".

PS: I'm running Linux for 9 years, using unstable/development branch for 5 years, and doing auto-updates on servers with _carefully chosen_ distro for 4 years. So far, it was rather worth it though I could catch one unpleasant upgrade (be it manual or auto, my configuration was quite peculiar and asked for much attention) with stable+updates and reasonably rare disasters, like last morning's X breakage thanks xorg folks auto-enabling Composite in server-1.4 and me using WindowMaker, on unstable side.

PPS: no, not Debian -- ALT Linux here. :)

#

The dangers of automatic updates

Posted by: Anonymous [ip: 75.44.189.134] on September 14, 2007 10:57 PM
For day zero vulnerabilities I think it's great to have auto updates. at least there is a chance of updates before I get hit w/ some security issue.

#

The dangers of automatic updates

Posted by: Anonymous [ip: 127.0.0.1] on September 14, 2007 11:00 PM
I'd have to agree with lack of information on updates being a problem. I had an unstable system on Fedora 6 and it never seemed to get better, not matter what updates I applied. I was really irritated with the lack of information on updates. I don't know if I will go back to Fedora after that experience. Unless your someone who just wants to spend their extra time in working on a system or checking out the latest and greatest why subject yourself to the instability of constant updates.

#

Re: The dangers of automatic updates

Posted by: Anonymous [ip: 24.192.193.243] on September 22, 2007 06:59 AM
i do have to agree with you about Fedora 6 it did become unstable ( Nautilus did ) but so far Fedora 7 has not had a problem
when pup runs at login i take a look ( and install the new kernel by its self , i have an old, old nivida card and will need to rebuild the driver ) .

#

Trust and Ignorance

Posted by: Anonymous [ip: 208.101.168.53] on September 15, 2007 03:03 AM
With so many people switching from Windows to easy-to-use Debian descended distros (or at least dual booting), you have an increasing number of people who don't understand the change description (that's assuming one's there to begin with). I don't know how many changes I've seem where the description was in serious geek-speak. It's often the opposite of the Microsoft descriptions, which tend to be uselessly generic ("This patch fixes a vulnerability which may result in someone taking control of your computer"). Unfortunately, the result is the same: people know this is a fix, but they have no idea what it's for, so they're forced to trust the source of the patch.

Is this trust misplaced? I know in the case of Microsoft, I've come to believe it is, as some of the patches they've dangled in front of my face have turned out not to be in my best interest (e.g., WGA Notify). This has not happened to me yet with Ubuntu. Maybe I've been lucky.

I would like to see clearer descriptions on Ubuntu patches (or in some cases, *any* description). Lacking that, it comes down to a matter of trust, and whether you're taking a bigger risk in *not* applying the patch.

#

The dangers of automatic updates

Posted by: tomws on September 15, 2007 03:06 AM
It comes down to choosing the lesser of multiple evils. Something like Debian with 'stable' repositories is great for only getting necessary updates, but then you lack the newest releases with the wet paint. On the other hand, use a Fedora to get those releases, but get yourself some occasional trouble with conflicts (I had a broken BIND back in February - ouch!). It's no different from Microsoft Update in that respect, except 'only' your OS is broken there if a quick update goes wrong.

By the way, with Mandriva you can use urpmi and select only security/bug-fix updates. It's a good tool for a good distro. For work, though, I prefer the Debian Way of everything just working together.

#

A few corrections.

Posted by: Anonymous [ip: 69.153.132.227] on September 15, 2007 05:28 AM
In Ubuntu;
You can chose Security, Recommended, Pre-release, Backports, or any combination of those.
You can pin packages.
You can update part of the list.
You can get descriptions and changes.
You can check for updates, Daily, Every 2 days, Weekly, or Every 2 weeks.

Your problem is not a linux problem...

#

Re: A few corrections.

Posted by: Anonymous [ip: 193.166.94.185] on September 15, 2007 11:25 AM
AFAIK, universe and multiverse are not officially supported in Ubuntu -- in other words, they don't get security fixes from the Ubuntu security team. Ubuntu gets most of their universe and multiverse packages from Debian unstable, some from Fedora, and some from the unofficial repositories available via apt-get.org. These packages are potential security risks and they are not guaranteed to work at all.

Pre-release packages can only be recommended for advanced users who can fix things when they get broken. Last time I looked, Ubuntu's backports repo was almost empty. Pinning is too difficult for normal users. Normal Ubuntu users should make sure that universe and multiverse are NOT enabled and they should stick to official Ubuntu releases. They should also install security updates as soon as they become available, although any updates have the potential risk of breaking your system. Unofficial package installers, like Automatix, should be avoided.

#

The dangers of automatic updates

Posted by: Anonymous [ip: 88.91.65.202] on September 15, 2007 06:46 AM
A correction: Debian never pulls anything from experimental unless you specifically ask for it. Also, every feature in Debian is aimed at users of the stable branch which only receives security updates and bug fixes. And if you use stable you should never include any of the other branches anyway. So with those prerequisites the auto updater is fairly safe.

You don't want auto updating if you use testing/ unstable of course, but then again if you use any of those you are expected to take care of your self ;)

#

Pinning experimental in Debian

Posted by: Anonymous [ip: 62.227.198.142] on September 15, 2007 09:27 AM
It's quite easy, just write the following in /etc/apt/preferences (create it if not there):
Package: *
Pin: release a=unstable
Pin-Priority: 900

Package: *
Pin: release a=sid
Pin-Priority: 900

Package: *
Pin: release a=experimental
Pin-Priority: 100

now, you have to explicitly say that you want a package from unstable

#

Re: Pinning experimental in Debian

Posted by: Anonymous [ip: 205.208.133.240] on September 17, 2007 01:29 AM
Don't you mean that you have to explicitly state that you want a package from experimental?

#

Re: Pinning experimental in Debian

Posted by: Anonymous [ip: 69.81.118.3] on September 17, 2007 11:55 PM
How is a n00b supposed to know that? TFA is about newbies, not about people who know what they are doing.

#

The dangers of automatic updates

Posted by: Anonymous [ip: 194.237.142.11] on September 15, 2007 10:33 AM
I'm glad you brought that up. This debate is really hot in Linux Mint at the moment, as we've remode the Update Manager from the upcoming Celena release and get ready to develop a tool called mintUpdate.

http://www.linuxmint.com/blog/?p=54
http://www.linuxmint.com/blog/?p=71

As you can see, a lot of our users are furious... I find it really hard to make my point. Hopefully your article will help.

http://www.linuxmint.com/forum/viewtopic.php?t=5188

Regards,
Clem.
linuxmint.com

#

Taking the easiest road

Posted by: Anonymous [ip: 82.95.249.161] on September 15, 2007 11:17 AM
I have to solve the problems of those around me that aren't specialists.

Turning automatic updates on by default saves me time just by solving more problems than it causes.

What problems remain, I look for solutions by searching the web.

There is no solution that has no exceptions...

#

you could always

Posted by: Anonymous [ip: 82.71.19.188] on September 15, 2007 11:21 AM
switch to Slackware, and only take the security updates; you couldn't
get much more stable and conservative than that.

#

The dangers of automatic updates

Posted by: Anonymous [ip: 86.136.61.161] on September 15, 2007 11:35 AM
I autoupdate my Debian Testing and thus far I have had problems (Nvidia binary and Xorg fell out, thats what you get when you use closed source) but the benifits have been worth it in my opinion.

But there is also Debian stable for those who don't want the risk of updates. Something for everyone.

#

The dangers of automatic updates

Posted by: Anonymous [ip: 83.104.43.51] on September 15, 2007 11:57 AM
I have to say that from my point of view as a desktop Linux user this article is utter crap.



Have I ever experienced "Conflicts between programs, unresolved dependencies, and broken systems" despite the fact that I apply every update that comes along and have done for the past 3 years? Nope. Not once. Don't updaters actually *check* for missing dependencies, anyway? Mine seems to...



I happen to trust that the person who wrote the software I'm using knows more about it than I do. Seems to work fine for me. I suppose it will be because I'm a trusting idiot. You must know better than the people who wrote the software, right?



What else do you expect anyone that's not an active developer within the community to do anyway? How do we make the decision to apply an update or not?



Granted any update on any system may introduce bugs that weren't there before, but in my experience applying updates solves many more problems than it creates. How bad did the Windows world look just a few years ago when people weren't applying updates when the system prompted them to? Does anyone remember msblast? That was fixed weeks before the exploit did the rounds, and how many people got caught because they didn't update? What are you suggesting we do instead?

#

Re: The dangers of automatic updates

Posted by: Anonymous [ip: 87.69.52.45] on September 15, 2007 01:29 PM
I totally agree with you. Running Debian Sid here and applying every update available i never had a problem: apt is an excellent system and just refuses to install package that have unresolved dependencies (don't know about RPM, though).
Windows world is different: less you let your system to "call home", more the chance of your private info does not sent to M$.

#

Re: The dangers of automatic updates

Posted by: Anonymous [ip: 71.30.71.115] on September 22, 2007 02:07 AM
How do you know the updates solved a problem? Because someone said they did? And is it a serious problem? I don't know the ins and outs of my system a well as the people who created it, but I also know that when you throw thousands of packages together and change a few just a bit there could be problems. You're lucky you haven't had any problems, but that doesn't mean no one else has. Don't be a lemming.

#

The dangers of automatic updates

Posted by: Anonymous [ip: 71.131.219.176] on September 15, 2007 04:43 PM
Only issue I"ve had with the openSUSE 10.2 updater is that when mirror directory structures is changed, the Updater apparently doesn't deal with it except by giving a fairly cryptic message. You have to know to go look for the source list and change it.

The other problem with it is exactly the frequency of updates. I get an update alert every day or two saying "1 (or 2) update available". Most of them are security updates, so it's no big deal. But the problem is that every day I allow it to apply that update, it's a five minute exercise where it rebuilds the entire repository catalog before applying that one update.

Reportedly this will be fixed in version 10.3, due out shortly.

In general, whether updates tend to break your systems depends on the quality of the system in the first place and the quality of the maintainers. openSUSE has given me no problems at all with the updater (once their Zen crap was disabled - that is a piece of junk). On Kubuntu, using Synaptic, if an update fails, you have to go to the command line to unlock the database - it was an annoyance several times and would be a show stopper for a naive user. Kubuntu was much less stable than openSUSE in my view in several ways, including KDE bugs and other minor matters that eventually became too irritating, forcing me to switch to openSUSE.

#

test only one update at a time, test only one update at a time, test only one update at a time...

Posted by: Anonymous [ip: 67.81.182.91] on September 15, 2007 05:04 PM
A few years ago, I had several dozen Sun SPARC servers, in a private network, running, under Solaris, the jobs that pay the bills. The only time those servers' operating systems were updated was to solve a problem. The consequence was cumulative uptime in the five nines: The only significant events during that time were the WTC's demolition and a large regional power failure, but only the power failure stopped the financial processes that run on those computers.



In the last four years, those dozens of Sun servers have been replaced by no-name, high-end, PCs, with AMD processors in arrays of 1U, 2U, 4U, etc rack enclosures. The operating system used is a Fedora that I have vetted and sometimes modified with a different device driver for servers that have special boards. There are two consequences from that change: savings and reduced availability. Our budget dropped because instead of paying Sun in the high six figures for a maintenance contract, we now spend about 100 grand on new hardware every year. The reduced availability is caused by the lower quality of the commodity, PC hardware that we buy as well as an expected shorter working lifetime for PC equipment than our old Suns. As a matter of fact, we decommission our AMD servers when they become two years old because we don't want failures caused by low grade, printed circuit board manufacturing or failures caused by the drying out of low grade capacitors.



The benefits of switching from Solaris to Linux are mixed. We have faster hardware which allows us to try new computationally intensive approaches at a much lower cost. Our availability decreased from five nines to four nines, but we address that by having many more servers to shove into the breach. We have noticed that the Linux TCP stack seems to be slower and of lower quality than the Solaris TCP stack.



We keep those servers running by not changing their operating systems. If the jobs that pay the bills can run, there is no reason to change any computer's software. That does not apply to our applications which change as often as necessary to make a profit. The point is that the computing base for the applications is always dependable and predictable.



In our environment, there are also desktops; some run Ubuntu, a few run Fedora, and the rest run Windows. We maintain local, private mirrors of the Fedora and Ubuntu repositories although automatic updates are disabled. If a user needs to change something, it's easy to make the requested upgrade, but we try not to fix what ain't broke.



When a change is significant, that means that the processes that pay the bills could be negatively affected, we try the patch on a test computer and test and test and test. If the patch passes muster, it gets added slowly to the systems that need it, never all at once to all systems.



Open source software is a great way to reduce operating expenditures drastically, but we learned the hard way to not change our computing platforms without testing things ourselves, for our needs, in our environment.

#

Re: test only one update at a time, test only one update at a time, test only one update at a time..

Posted by: Anonymous [ip: 85.216.76.151] on September 16, 2007 01:46 AM
Interesting article praising Sun hardware and claiming that alternative hardware is crap. Reality may be different for different people. A company that I worked for had Sun because the maintenance contract had a 24h max replacement time of the hardware back up running. (special customer software not included). You won't get that from ASRock on their Mainboards, but if you look around you may find companies giving you AMD pizzaboxes for a reasonable price with reasonable lifetime. You always have to pay for good support. If you are running mission critical things on home-built PC hardware, I think that is more an isolated problem of yours, not the fact that free and open source software is developing. Updating is always good, but the updates have to go through testing, and that is what is currently missing in some of the free and open source projects available today.

#

Re: test only one update at a time, test only one update at a time, test only one update at a time..

Posted by: Anonymous [ip: 24.184.183.244] on September 16, 2007 06:14 PM
"The reduced availability is caused by the lower quality of the commodity, PC hardware that we buy as well as an expected shorter working lifetime for PC equipment than our old Suns....."

In our facility, Sun hardware fails just as often as Dell/HP. Ever opened up a Sun server? Many of the components are made by the same companies in the same manufacturing sites in China/Korea/Taiwan. Broadcom chipsets are a good example. Unless you have clear evidence that Sun somehow sources higher quality components, all we have is anecdotal evidence.

"We have noticed that the Linux TCP stack seems to be slower and of lower quality than the Solaris TCP stack. "

Maybe, but you're just trolling unless you have something to back that up.

#

Amen

Posted by: Anonymous [ip: 216.141.24.91] on September 15, 2007 08:14 PM
I have felt this "update mania" crap to be annoying for years now. Seems like every piece of software is now constantly harrassing you about "updates". What I want is factual information about just what the "update" does. Everything it does. When I have found factual information about software updates, most of the time I see that the update will add some "feature" that I do not need or want, or fix some problem that I am not experiencing, or is related to using the software in a manner which I am not using it. When I say "most of the time" I'm talking about near 90%. That is, there have been rarely any "updates" to software that have ehanced my ability to do what I want to do with my computer(s). Which is why I HATE the "auto update" crap which wants me to just blindly "update" stuff. I know 90% of it will not do anything positive for me and I can only hope that it is not a negative. Now, that is not saying that I do not appreaciate doing a distro upgrade every few years or so, where I wipe the drive clean and put on a newer version of something. That has mostly been a positive experience. Or, upgrading some libraries in order to try some new software that didn't come with the distro. But, just constantly "updating" stuff all the time seems like a dog chasing it's tail.

#

The dangers of automatic updates

Posted by: Anonymous [ip: 24.80.34.124] on September 15, 2007 08:34 PM
I have to say, my favourite Linux distro (Mandriva) gives security and bug fixes in updates. No backports unless you set it up to include them. I did not know that other distros were so generous with their backports that they made them for all their recent releases. Of course source based distros would behave as you say as does Arch Linux. People running those distros are supposed to be able to fix them if necessary and should expect instabilities just like someone running Debian Sid.

#

The dangers of automatic updates

Posted by: Anonymous [ip: 192.223.226.5] on September 16, 2007 01:45 AM
I happen to be a proponent of choice in software, and I believe that an intelligent and reasonable default is the way to go. I happen to think that going with the Debian or Fedora or Slackware update as the default choice is the way to go, particularly for inexperienced users or busy users who do not have the time to research every update.

On the other hand, I do believe that having the option to disable blind updates should always be available and the experienced administrator should always have that choice. However, i do feel that the default ought to be to simply go do it.

Clem from Linux Mint seems to feel that blindly taking the default is no longer a good thing. Perhaps he has some solid reasons, but without completely appreciating what they may be, I respectfully disagree. I think you should have the OPTION to turn off running the enitre set of updates, and the OPTION to sift through them, accepting this one, rejecting that one. Even so, the default ought to be JUST DO IT. Most people have neither the time nor the energy to research them. For the most part, the application owners are in the best position to make that call. If you have enough information to dispute their opinion, then you should use the OPTION. But I contend that making the standard approach to do the update is the best way, keeping the flexibility there for those that don't. Make it easy for the novice, not easy for the experts, who know what to do anyway. Feel free to disagree. I think multiple APPROACHES is what makes free software so useful and so valuable.
Brian Masinick

#

Re: The dangers of automatic updates

Posted by: Anonymous [ip: 71.30.71.115] on September 22, 2007 02:45 AM
Here is what Clem said in his blog post:
"An uneducated upgrade is an upgrade performed by a user who doesn’t understand the risks involved in upgrading his package base. Of course, the user is not to blame, what is to blame is the fact that a complex process was made trivial to users without educating them on the risks involved.

In Celena we’re removing all that.

* The update notifier will be removed so you won’t get notified when new upgrades will be available. Upgrading will be a process triggered by you through APT or Synaptic, not by the system.
* The update manager will be removed so you won’t be asked to upgrade to Gutsy.
* The backports and proposed repositories will be disabled so even if you actually upgrade manually, you won’t make your system unstable.

For Celena->Mint 4.0 upgrades we’ll come with a Mint tool or we’ll rely on a command line operation. In any way we don’t want people to upgrade their systems without good reasons to do so. From our experience, and with our fast release cycle, stability on your desktop is more important than getting the latest security updates.

Advanced users will still be able to get them, but it will be up to them to launch upgrades or to reinstall the notifier."

You can still make upgrades, but at least you're a bit more involved.

#

The dangers of automatic updates

Posted by: Anonymous [ip: 85.216.76.151] on September 16, 2007 01:57 AM
For whatever context is this article written? Work or leisure? I work with RHEL4 in my product environment and I have almost no SW installed that make Linux what it is: An efficient work environment from both command line and window manager. At home I run gentoo and I am suffering from the knowledge that KDE is in version 3.5.7 and not 3.3, many additional applications for KDE is not available from rhn. If the author of the article want to produce critisism vs. current package management, he should do so instead of tunneling his frustration towards those who take the risk to help Linux move on by doing those beta-testing tasks. For a production system I should agree that updating is on a need to do basis. At home, well who cares.Maybe the moderator of a linux mailing list........

#

The dangers of automatic updates

Posted by: Anonymous [ip: 71.215.102.100] on September 16, 2007 03:35 AM
I am fairly new to linux and have stayed with simply MEPIS from the start. I have it on a laptop and a desktop. Only one really bad experiendce (maybe someone can help me resolve it). Some recent update dis something that makes Bibletime unable to add books tro its book shelf - or even connect with it's server. Or maybe that problem came from somewhere else. It onlyh affects the desktop.
Anyway, I'm glad for the discussion. I think what I might do is set up another partition and run all the updates on one, but onnly stable updates on the other.
LittleJoe5555

#

The dangers of automatic updates

Posted by: Anonymous [ip: 124.171.252.145] on September 17, 2007 12:10 PM
Have been using Ubuntu Gutsy Gibbon for since Alpha 1 and have it autoupdating and sending me email on all updates that get released in the time of gutsy gibbon been release only had two problem they where easily fixed eg just rerun dkpg --reconfigure with the i receieve daily email get a full list of all packages been updated plus any problems with this updates;

#

The dangers of automatic updates

Posted by: Anonymous [ip: 161.12.7.4] on September 17, 2007 12:45 PM
I'm annoyed by this "if it aint broke don't fix it" technique you talk about.

For example, you decide you want application X now, since it can make your life easier. Application X requires W, Y and Z updated which then requires your whole system AND a kernel upgrade... You spend 3 hours updating your system and you decide Linux is a c**p system for getting new programs.
How about another example, where you don't upgrade the kernel and have some network stack vulnerability? The kernel's not 'broke' - but you've suddenly had some code injected into your system!?
Each application in the stable repositories should be fine for updating every day, as they have been through testing. Any regressions in a stable release should be dealt with soon with the next release!

Secondly, this infuriates me:
"Of course, you might say that users should know better than to be so careless. But the fact is that it's easy to make mistakes when you are distracted or careless"
Well, how about this:
"You might say people shouldn't kick babies. But the fact is it's easy to kick babies when you swing your foot and kick a baby!"
OF COURSE IT'S EASY TO BE STUPID IF YOU'RE STUPID!!

Person Y decides that they want to go from their STABLE system, and STABLE repositories - and start using DEVELOPMENT and TESTING repositories and then complain that their system all of a sudden doesn't work?
Are you the type of person who would give up using Windows XP/Vista and start using the windows 7/vienna that is still under development FULL TIME? Of course not! The same goes for AIX/macOS and what a surprise, Linux too!

Yes, Linux does have a reputation for continual 'beta', but they're continually GOOD and STABLE beta's.

Personally I don't pick auto updates because I like to have control over when and how my system updates - I manually tell yum (yes, a Fedora guy) to update and I am able to see what is upgrading and how it will effect my system.
Updaters do have ways to be improved - perhaps labelling them on what area they're updating (GUI/Sound/etc) - but I don't think Joe Bloggs needs to know the in's and out's of what's changed (although getting the info if required is vital).
Mr Joe Bloggs doesn't always need to know what specific buffer overflow and memory leak problems have been fixed, or what features have been added/changed (you can always revert to an earlier version).

"Never mind that this idea is an nuisance and an unwarranted assumption"
Then turn it off and leave it at that. Don't persuade others from updating their systems because YOU don't like it.

"contrary to responsible system maintenance."
_YOU_ may consider upgrading a system to be contrary to systems maintenence.. Then again, you may still be using VMS!

"They're an active hazard."
An active hazard? They're no more of a hazard then simply leaving the system as it is, and with the benefit that you're 99% more likely to BENEFIT from an upgrade, you're saying the reason to not upgrade is what?
"the reckless who have trashed their systems through unwary upgrades."
Trashed you say? They are called 'reckless' for a reason: that they didn't stick to stable repo's/packages.

I can go on, but I've written too much already!
== Paul_one ==

#

The dangers of automatic updates

Posted by: Anonymous [ip: 209.74.48.98] on September 17, 2007 04:31 PM
I switched to live CD's because of update problems.

#

How Debian does it

Posted by: Anonymous [ip: 67.90.11.226] on September 17, 2007 09:25 PM
The author didn't seem to have a very solid grasp of Debian's package management system.

There are *no* automatic updates in Debian unless you do something like set up a cron job to check each day. Also, there aren't any buttons to click on with the currently recommended apt front-end (Aptitude) or the venerable apt-get (which was only supposed to be a "proof of concept" program, but wound up working better than anything else in the world in its category). These are both command-line utilities (Aptitude also can be used with an ncurses-based interface). Maybe you're referring the the gtk-based Synaptic.

So, to check for updates, you type "aptitude update" (or "apt-get update") to synchronize the package database with the repositories on you apt list. Then, you type "aptitude upgrade" to check for what packages have newer versions available, including any dependencies. All of the affected packages are listed. You can block updates of specific packages if you like with "forbid-version".

Now, the net effect depends greatly on what repositories you have in your sources list (/etc/apt/sources.lst). If you are running the Stable distribution, as you should be in any production environment, all you will get are security and other important bugfixes. There will not be any new features.

If you are running testing or unstable, you will get new versions via the above process as they migrate into Debian. "Testing" will avoid the most dramatic breakages, because packages don't get to "testing" until they have been in unstable for two weeks with no critical bug reports. However, any fixes also will need to spend two weeks in unstable before they get to testing, so testing isn't necessarily more "stable". "Experimental" is really just for package developers.

Also, Debian "unstable" doesn't mean "crash-prone" - it just means "constantly changing". I am the upstream developer for two programs in Debian, and releases go into "unstable" at the same time they are posted for public download outside of Debian, and sometimes significantly later. By the time a package gets into "unstable", it has generally had a reasonable amount of public use.

#

Re: How Debian does it

Posted by: Anonymous [ip: 86.123.200.16] on September 21, 2007 09:19 PM
um... no. Actually you're the one who's lagging behind. Etch, in gnome at least, has the annoying "new updates" pop-up just like ubuntu does.

#

Re(1): How Debian does it

Posted by: Anonymous [ip: 209.193.111.198] on September 25, 2007 04:03 PM
I agree with the first commenter. If I am running X and Gnome, it is not a server. Why would a desktop user be using stable? Servers should be on stable. One other thing to add to the first commenter, once you have everything set up the way you like you can use just the security repo's. That way you will only get bug fixes and their dependencies. On a side note, since woody I have very rarely had a problem with doing updates on debian. I must be much more careful on a centos box. I get a distinct feeling that the author is buying into the riff between debian and rh distro's.

#

Red Carpet

Posted by: Anonymous [ip: 72.174.222.239] on September 18, 2007 05:03 AM
Red Carpet, and rug it's command-line tool, was pretty good because it'd allow you to set it up to only auto-install certain types of updates such as security fixes and you could exclude certain packages or any package that'd require your blacklisted packages be updated. It's to bad that Novell screwed Red Carpet up when they bought Ximian because it's still the best package manager I've used.

For the average person I think automated updates work well. It eliminates the idiot factor in updates being applied. Those of us doing stuff that an update is likely to break are experienced enough to know how to disable automated updates.

#

windows updates

Posted by: Anonymous [ip: 56.0.103.24] on September 19, 2007 06:36 PM
"if it ain't broke, don't fix it" explains why windows constantly nags for updates.

#

Distro-specific

Posted by: Anonymous [ip: 75.211.73.171] on September 21, 2007 08:16 PM
So far I haven't had an Ubuntu auto-update do anything silly (from Dapper right through the current Feisty), with the SOLE exception of Wine which at some point (9.30 or 9.40?) broke Internet Explorer. I've now pretty much abandoned Wine as too craptastic for my tastes and gone with Virtualbox and real WinXP for my rare Win-code-needed situations.

During the three months I lived with Fedora Core 6, auto-updates blew up components twice. Not BIG blowups, easily fixed and no data loss, but still the sort of thing that would drive an "Aunt Millie" non-tech user bonkers.

It comes down to "can you trust the update prep team?". In Ubuntu's case, my experience says "yes".

#

The dangers of automatic updates

Posted by: Anonymous [ip: 88.252.30.69] on December 12, 2007 01:53 PM
<a href="http://r10noktanet-seoyarismasi.blogspot.com" title="www.r10.net küresel ısınmaya hayır seo yarışması">www.r10.net küresel ısınmaya hayır seo yarışması</a>

#

The dangers of automatic updates

Posted by: Anonymous [ip: 88.226.154.98] on December 14, 2007 03:42 PM
<a href="http://www.felek.us" title="felek">felek</a>
<a href="http://www.2zler.com" title="komedi">komedi</a>
<a href="http://www.msnavatarlarii.com" title="Msn Avatarları, Msn İfadeleri, Msn Göz Kırpmaları, Msn Nickleri,msn ifadeleri, msn avatarları, msn ıvırzıvır">msn</a>
<a href="http://www.msnavatarlarii.com" title="Msn Avatarları, Msn İfadeleri, Msn Göz Kırpmaları, Msn Nickleri,msn ifadeleri, msn avatarları, msn ıvırzıvır">msn avatarları</a>
<a href="http://www.2zler.com" title="2zler, felek, video,komik videolar, komik video, fıkralar, komik fotoğraflar">komedi</a>
<a href="http://www.2zler.com" title="2zler, felek, video,komik videolar, komik video, fıkralar, komik fotoğraflar">karikatür</a>

#

The dangers of automatic updates

Posted by: Anonymous [ip: 88.235.147.68] on December 22, 2007 07:53 AM
Thanks ....
<a href="http://www.kalbimegir.org" title="mp3 indir" target="_blank">mp3 indir</a>
<a href="http://www.johnnydeppfantr.com" title="johnny depp" target="_blank">johnny depp</a>
<a href="http://www.cileknet.info" title="cilek" target="_blank">cileknet</a>

#

This story has been archived. Comments can no longer be posted.



 
Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya