On Fri, Oct 30, 2009 at 6:35 PM, Stuart Jansen <[email protected]> wrote: > 4) Let things break. If they want to avoid the upgrade treadmill, they > should be using an LTS release.
For several people they needed the newer functionality provided by certain applications which were not backported into the previous LTS release and didn't want to wait another 18 months to install their system. I realize part of the problem is that Ubuntu doesn't do a rolling release, but for better or worse it is the distribution we've selected for desktops. > Using an old distro endangers not only > them, but everyone sharing resources with them. So long as they're > connected to the Internet, that includes me and I don't appreciate your > attempt to make it even easier for scumbags to create spam zombies, etc. I recognize and agree with this for the most part. This is, however, somewhat mitigated in this case because these machines are all internal to BYU's network, and all have internal IP addresses. Most of the people currently using the older releases do not wish to upgrade because of the hassle this brings. They have a working system and don't want to break that (something I am sympathetic to). I'm not trying to do anything heroic for these out-of-date users. Ubuntu keeps the old repositories available at old-releases.ubuntu.com and these users could just change their apt settings to use this repository. I was just hoping to avoid that so that they still have access to a fast and local mirror without needing to worry about changing their settings. This should be, I think, a goal of any IT group -- when users don't have to think about IT it means the IT group is doing a good job. I suppose this is really just a weakness of non-rolling centralized package repositories. In any case, I wasn't really looking for an argument on the circumstances surrounding my question, rather just wondering if anyone had any ideas for the puzzle it presented. Thanks, Nick -------------------- BYU Unix Users Group http://uug.byu.edu/ The opinions expressed in this message are the responsibility of their author. They are not endorsed by BYU, the BYU CS Department or BYU-UUG. ___________________________________________________________________ List Info (unsubscribe here): http://uug.byu.edu/mailman/listinfo/uug-list
