On Fri, Nov 25, 2011 at 6:08 AM, David A. Bandel <[email protected]> wrote: > On Thu, Nov 24, 2011 at 18:11, Chris Travers <[email protected]> wrote: > > [snip] > >> >> Ok. So with a server, my primary concern is that upgrading things is >> always a somewhat risky process. Basically, when you upgrade, you >> risk breaking things, so generally speaking you want to have longer >> terms of support and a more lazy upgrade cycle. And there are a >> couple things about the Fedora upgrade process that are particularly >> risky. For example yum distrosync will upgrade major versions of >> PostgreSQL for you, meaning if you didn't dump your data first, your >> PostgreSQL db is now unusable. > > I hope you're joking. While a Debian upgrade is not the easiest thing > in the world (they do their best to make it so, though), at least this > is not an issue. You run postgresql versions in parallel until you > finally get rid of the old one because the new one works properly for > you.
I am not joking. I always back up before an upgrade.... fortunately.... but I have noticed this happen. > > I've gone through 8.4->9.0->9.1 (and many before I can't remember) > upgrades w/ no problem (personally I use testing, even for my own > servers). With Debian, they leave both database versions running > until you've dealt with any upgrade issues. So far, I've only had > one, that was when a contrib stored procedure I was using didn't make > it from 8.4->9.0 (but it appeared again in 9.1). That's the right way to do things. <snip> > >>>> >>>> The problems that Darald brings up are real ones. There may be >>>> advantages for us devs ignoring these and working on short-term >>>> support releases ourselves. However I would not today use these in >>>> setting up servers for customers. >>> > > As I mentioned before, I find Debian testing to be sufficiently > bleeding edge to catch problems before my clients see them -- and yes, > I eat my own dog food (a la Debian testing). I would never suggest > Debian unstable (they really should call it Debian broken, as it > usually is). Unstable is unstable? Whoda thunk? > > I diverge from Debian testing on one point: > Except for _base_ Perl modules, I load and update directly from CPAN. > I'm actually not sure why distros don't just do this. It's a lot > easier than trying to keep thousands of individual modules updated. > >>> >>> Agreed. >>> >>> >>>> Debian is not a bad distro, and neither is Scientific Linux. > > Scientific Linux will likely be Debian testing -- guess I should check > it out sometime. While CentOS is an RHEL clone, Sceintific Linux is an RHEL extension. It's RHEL plus other things built from sources..... > >>> >>> >>> I might have a look at a virtual SL setup now on your recommendation! >> >> Scientific Linux has a couple things to recommend it as a Server OS. >> >> 1) It tracks Red Hat Enterprise in both support and versions. >> 2) It includes a lot of things that RHEL doesn't include >> 3) They beat CentOS to releases. >> 4) They are backed by heavy Linux users (Fermi Labs, CERN) > > I believe we do need devs using both RH and Debian based development > platforms (though not necessarily both), and it sounds like that's > already happening. Yep and has been for the entire history of the project. > > I have had in mind putting up a Debian stable Virtual Box image w/ > LedgerSMB that users could just import and go. Guess I'll need to > work on that ASAP. But will also put up a Debian testing development > environment (with a few extra goodies) built from svn. Virtual Box's > clone facility makes this task easy. > > I guess I could also put up an RH-based box as well, although it is > probably better if someone more familiar w/ RH did that. It's been a > few years since I admin'd anything RH based (so long, in fact, that > yum didn't exist). > Understood. Best Wishes, Chris Travers ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ Ledger-smb-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
