[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
Neil Williams wrote: > On Thu, 2008-11-06 at 13:41 +0000, "Philip Radford" wrote: > >> I am writing knowing that Debian (or its derivatives) is the OS of choice >> within the group. >> >> Just got myself a brand new dedicated server as the next logical step up >> from a shared hosting platform. >> > > Servers should use stable, or at most testing. Specific packages can be > backported to stable and the 10 day delay in migration from unstable > into testing will save you a lot of downtime. Right now, servers should > consider migrating to 'lenny' as the codename in the sources lists. > > Thanks for your comments Neil, I will investigate Lenny and have taken on board your comments regarding the unstable versus stable repositories. >> I decided to go with Debian 4.0 (Etch) 64bit as the OS of choice and was >> wondering if anyone had any advice on whether to install packages from the >> stable or unstable branch. >> > > Intel or AMD? (ia64 or amd64) > AMD64 is the 64bit architecture. >> I have currently gone with the unstable branch after reading the advice on >> the debian web site. >> > > ? Eh? What advice? The website does not recommend unstable for servers - > unstable is not "recommended" in most cases. > > I now realise this and have already reimaged back to the etch base install and will only now update from etch repositories until I can update with lenny. >> I am keen to utilise the latest versions of Apache and >> PHP for my web applications which work in a LAMP environment. >> > > That is the *wrong* reason to use unstable. Unstable is for development, > not deployment. Run unstable at home but only stable or testing > remotely. > > Unstable *WILL* break, that is why we call it unstable. It is allowed to > break and it regularly does break just as soon as the release freeze > ends. It takes a significant amount of time for unstable to settle down > after the post-release frenzy - during this time, the thing servers > should be running is the just-released stable (which at that point is > still very close to testing). > > As soon as Etch was released, the cry went up "Yey! let's get back to > breaking unstable!". It will happen again with Lenny. Getting the > release right takes such an amount of time that loads of updates and new > versions cannot be uploaded, cannot be fully tested. When all those > pending uploads are actually made, things will break. Promise. > > >> What are the chances of coming unstuck in the future if I continue to use >> the unstable branch? >> > > Right now? Unstable ~= testing == Lenny because of the freeze so you > will get a completely misleading impression. > > Immediately after the Lenny release? 90% chance of failure of unstable > in at least one LAMP package or direct dependency, 100% chance of some > failure elsewhere (probably something related to the perl 5.10 > transition or the python transitions). > > It will only settle down when all the uploaded packages have all > completed their migration into testing. i.e. testing is where you want > to be for new stuff that actually works. I think that is usually an > important criterion for a server but your mileage may vary (if you are > mad). > My mistake was to not realise that security patches are built back into previous releases. Therefore the security benefits of a 2.2.9 apache package are available within the 2.2.8 package on etch. At least that's what I have been led to believe. Thanks for the explanation on this. Very informative and now makes sense to me. In summary, I will keep my eye on the lenny (testing) branch. But as they always say, if it ain't broke, don't fix it. Phil. Cornwall. -- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/linux_adm/list-faq.html