Re: Dreamhost dumps Debian
Excerpts from Kevin Chadwick's message of 2013-08-27 11:45:34 -0700:
> > > Large hosting companies not having made their scripts etc. good enough
> > > to ride out upgrades well should have nothing to do with any decision.
> > I don't think the problem here is with "Large hosting companies not
> > having made their scripts etc. good enough". I don't think it has
> > anything to do with size, or the type of company, or even the activity.
> > I believe that the short life cycles of our stable releases is a problem
> > for *MANY* companies. Dreamhost is the tree hiding the forest.
> I can't see how it can be such a problem if they have well written
> scripts. Run it on a new system, update the script or files to cater
> for any fallout, deploy and larger companies deploy to more systems so
> it is less taxing or more systems are deployed for the same effort.
> Do they need to get some kind of long drawn out certification like out
> of date Android images.
> OTOH towards the end of a debian stable life cycle (ignoring extended
> security support) you already find software that is problematic to run
> atleast for desktops due to requiring newer QT to compile etc., meaning
> it's often easier to use a chroot of Ubuntu etc. to run the latest
> kdevelop or ffmpeg with webm support (I admit I haven't delved into the
> backports yet as I only knew they existed recently, but would still be
> wary of any packages with far reaching dependencies).
Perhaps you missed the blog post  details?
"About ten months ago, we realized that the next installation of Debian
was upcoming, and after upgrading about 20,000 machines since Debian 6
(aka Squeeze) was released, we got pretty tired."
Even if the script is _PERFECT_ and handles all of the changes in wheezy,
just scheduling downtime and doing basic sanity checks on 20,000 machines
would require an incredible effort. If you started on release day, and
finished 2-3 machines per hour without taking any weekend days off,
you would just barely finish in time for oldstable to reach EOL. I
understand that they won't be done in a linear fashion, and some will
truly be a 5 minute upgrade/reboot, but no matter how you swing it you
are talking about a very expensive change.
This is one of the things driving people to the more cloud/IaaS model
where individual machines are not precious and comprehensive testing is
intrinsic to the whole process. For people who already are in that model,
wheezy's release is a couple of days of test/fix/push and then "yaaay! we
can remove all of our hacks to work around 3 year old bugs in squeeze."