Marden Marshall ha scritto:
On Sep 12, 2009, at 3:43 AM, Alberto wrote:
Hi Marden,
no need to say in my CentOs PBX system I don't have Firefox neither
the Gimp.
The real point here is: I'm happily running CentOs 5.3 and I
installed sipxecs via yum, it's a recommended best practice to
change CentOs repos to version 5.2? Could it lead to some untested OS
incompatibilities between versions? That of course might cause the
system not to be thoroughly tested as wanted?
Said that: you are in perfect right to manage repos file if sipxecs
was installed from the iso. And again you are in perfect right to ask
me to install a production system using only CentOS 5.2 or simply
stick to the version distributed with the iso.
But I believe you cannot predict why some user is using CentOs 5.3 or
5.1. They might support other software with different requirements on
the same box. I believe there are many reason that should suggest to
leave this decision to the admin.
We do not support a "clean install" of sipxecs via RPM's. The RPM's
are only provided to allow a user, who has previously installed
sipxecs using our supplied ISO, to perform a software update.
Therefore, to first install some random version of CentOS and then to
install sipxecs via RPM's, you do so at your own peril.
The fact the "clean install" via yum is not officially supported is
quite new to me. Definitely the iso as the "only" choice it is a new
requirement introduced with version 4.0.x, because before I always
preferred a "clean install", and as far I remember this was the only way
to install not so long ago. Just to mention what everyone can read the
wiki states the iso is the "EASIEST WAY" not the only supported way.
Anyway I respect that official support change, but I don't understand
why I'm allowed to install on an unsupported centos 5.3 (I did not see
any warning - probably it was introduced in 4.0.2?) and a yum update is
allowed to mess up my working system without even a warning.
Basically: do whatever you like on the supported iso, that is a self
contained full pbx, but let me try my own peril with the OS of my choice
not causing please more suffering than needed.
What is currently happening looks like an Office 2000 install that wants
to transform Vista in Windows 2k, instead of simply telling the user
"Sorry OS not supported".
As I said before I'm happy to use the ISO and CentOs 5.2 in a production
environment in the future, but is reasonable that my working systems
based on CentOs 5.3 get messed up for an yum update that has nothing to
do with the OS itself?
Don't like very much the statement about buying a commercial license.
Is the commercial product thoroughly tested against every possibile
OS software update? Was not the commercial product based on the same
code based of the open source one? What is compatible with last OS
update on the commercial product, which I believe could be a
super-set of the open source one, shouldn't be compatible with the
open-source?
For our commercial product, SCS, we supply the customer with the OS
and SCS software bundled together, i.e. an ISO install. We then
provide the customer with ongoing OS updates for their installed
system. These updates are supplied directly from Nortel's own
repositories, not from CentOS repositories. For example, when we
released 4.0 (SCS 3.0), we also included an OS upgrade which brought
the customers servers from CentOS 5.1 to CentOS 5.2. If we deem that
it is beneficial to our customers, we will, in a future release,
upgrade their servers to CentOS 5.3, etc. In all cases, we only
release these OS updates after they have been thoroughly tested in
conjunction with the SCS software and our recommended server hardware.
What I see here is an unnecessary and potentially disruptive obsession
over what version of OS is running on ones PBX. Do you worry about
which version of VXWorks OS is running on your Polycom phone or which
version of Linux is running on your Snom phone? I'm certain that you
do not. Instead, you rely on the vendor to deliver a solid working
combination of OS and application software. That is exactly what we
are trying to accomplish here.
Perfectly clear. But sorry, this does not justify the suggestion you
gave before to buy a commercial license. I'm sure there are better
reasons to do that.
Alberto
_______________________________________________
sipx-dev mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
sipXecs IP PBX -- http://www.sipfoundry.org/
