> I have yet to see a scenario where > automatic updates direct from the upstream vendor is a Good Idea on > production systems. Ok, here's one. My building has about 300 employees and one system manager. We're a university; that's what we can afford. Further, he's not an RHCE or an MSCE or anything else; he's a musician and this is his day job. We can't afford anyone with real credentials; they'd have to be paid more than the department chairman. Each person here has one or more computers. The mix is very heterogeneous, about evenly divided between Linux, Sun, Mac, and PC. The hardware is whatever was hot when the person bought the computer. There are no "recommended configurations" or anything like that; you get what you can get a good deal on and that fits your needs. Each senior person controls his own budget. Very few are people who would know what to do with a root password. The main tasks our system manager worries about are making new user accounts on the department's shared machines, installing and configuring new machines as people buy them, installing and configuring the third-party software they need, fixing hardware that breaks, and maintaining our servers. Needless to say, manually updating the 600 or so computers here is *low* on the system manager's list, but it's of course crucial that it happens, as are all the other things. So, automatic updates are the way we go. If an update were to break something (hasn't happened yet), people would squeal, he'd figure out what happened, and if there weren't another update forthcoming that fixed it, he'd write some scripts to back out the problem update and tell people to run them. Yup, folks, we're a zoo. And, the situation is the same in nearly every university department in the country, save for the mix of machines. Add onto our millions of machines those of private individuals, and you get a sizeable audience of people for whom auto update, no matter what the OS, is the best thing since the invention of ketchup. There are many situations where you wouldn't want auto update, some of which have been outlined here by people whose responsibilities cover them. In many of those situations, RH itself would tell the customer it should never be running Fedora, it should be running RHEL. Fedora's low cost and its declared experimental nature predisposes it to be run in situations like ours. If you don't believe that many people auto-update, do some statistics on your web servers for FC1. Calculate the *local* time of each request for the repo data (i.e., the first yum request). You'll have to do a lookup on the IP address and figure out what time zone they're in to do that. Then plot a histogram vs. local time. I'll bet money that you get more hits in the 4:00am - 6:00am range than during any other time. Cron.daily fires at 4:02 am and FC's scripts throw in a random delay of up to 2 hours. My point is simple: since auto update is very common and a good idea for many people, FLP should document the practice and gear its services to it. It means a little more care in putting the updates together, but not much, and certainly not more care than you are already taking. Gearing toward auto updates will not hurt manual updaters at all. Don't worry about making "formal recommendations" on whether to auto-update. Clearly, it's a good choice for some, a poor choice for others. Rather, write clear descriptions of the pros and cons. Anyone running Fedora is self-supported and had better be able to read the pros and cons and decide what best fits their particular situation best. --jh-- -- fedora-legacy-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-legacy-list
