Poll on ViciBox v.6.0

[Kumba]

Since having a CPU that is not 64-bit would require a 10-year old processor, I am proposing the removal of the 32-bit architecture in ViciBox releases starting with ViciBox v.6.0. Intel has included 64-bit instructions since 2004 on the P4 and AMD since 2003 on the Opteron. The performance difference to Asterisk and Apache is negligible if not immeasurable. The only real consequence would be a slight increase in the amount of memory used by the system. Any system with 2 to 4 gigs of memory or more should not be adversely affected by the switch to 64-bit. My best guess is that there would be a 10% or less increase in the amount of memory used by a 64-bit server when compared to a similarly loaded and configured 32-bit server. This should really only have an impact on those who are using less then 2-gigs of RAM. The primary ViciDial benefit would be to MySQL which is the only service in ViciDial that has a genuine need for 64-bit CPUs or more specifically the access provided by the CPUs to a 64-bit memory range.

The ViciBox benefits of such a move would be faster releases, better quality control, and less confusion on which ISO to download for those new to ViciBox. From my side as the developer and maintainer of ViciBox the primary benefit is that all my time would be spent maintaining one distribution as opposed to spending time making sure that the 32-bit and 64-bit versions do the same thing under all scenarios. It also limits the scope of bugs to just those that effect 64-bit versions and makes instructions for patches and upgrades simpler when those bugs do happen.

Still, in the end, ViciBox is a service to you the end users. So for that I request your input for the above poll.

As a side note, this also means that Vicibox v.6.0 should be coming by the end of April finally. There will also be another v.5.0 release to wrap up some of the lingering bugs with that distro including the 1.4 asterisk bug that we think we finally found.

[geoff3dmg]

Certainly in a production system I would never use anything other than 64bit (if nothing else due to the memory limitations of 32bit systems). I don't see a downside to this change.

[Kumba]

There's a case to be made for 32-bit but in terms of ViciDial and ViciBox it's pretty minimal.

[geoff3dmg]

The only thing I have thought of is testing/development systems running in a VM.

[Nefariousparity]

Honestly, Any Dell Power Edge 2900 stock with two quad core cpu's and 4GB of ram runs about $300 US. I have run on less and still maintained 64 bit. I don't think there is anything I use anymore that is solely 32 bit as far as hardware goes. I understand a lot of people are still stuck in XP land, but who is running call centers on Dell Optiplex GX 260's?

I vote get rid of it. Ten years was long enough to adapt.

[micom67]

I also think that 10 years is enough, and everyone in between, a performance strong server. in my opinion, man should stop production for 32 bit.

[Kumba]

Well that settles that. 64-bit only versions of ViciBox from here on out starting with v.6.0.

[williamconley]

While I think some users unable to "properly configure" a VM (or unlucky enough to have a Dell 1800 series) to use 64bit, I don't think there will be enough to make the case for the added work (especially considering how much they are paying for the software). In fact a case could be made that if those people who NEED 32-bit were forced to pay for the extra work collectively, there would probably be enough money for them to each just purchase a 64-bit machine and not bother. Which means if you switch to just 64-bit, that's where we are. Seems fair that way. LOL

I think we had one client in the last 12 months who required 32-bit because of an old server that simply didn't like the drivers on any of the 64-bit disks.

[DomeDan]

I use HP Proliant G3 servers in production because its the most reliable hardware I've tested, I see no reason to upgrade because it works good.
Isn't there a multi-arch version of opensuse like it is for debian?
sure it needs more testing but I think its wrong to ditch 32bit

[Trying]

Too late! LOL

[williamconley]

I use HP Proliant G3 servers in production because its the most reliable hardware I've tested, I see no reason to upgrade because it works good.
Isn't there a multi-arch version of opensuse like it is for debian?
sure it needs more testing but I think its wrong to ditch 32bit

Although you did not state which processor you are using (unless you imply that HP Proliant are all 32-bit? LOL), I will assume that you have 32-bit processors in your servers. What is your processors model number?

Regardless: This will not impact your ability to keep these servers in production. Nor will it stop you from Upgrading (most likely, as Vicidial itself is not "OS dependent", you may continue to "upgrade in place" for years if history is any indication). It would stop you from reinstalling with Vicibox 6, but not from reinstalling with Vicibox 5.0.3 which at this point still installs the latest version of Vicidial even if the OS is a bit behind. The only real danger there is that the repositories for the OS will eventually go offline (of course, you could rsync your own copy right now and not care when that happens) plus the security upgrades/updates that will eventually Stop Happening. If you lock your system down (iptables, whitelist), that should not be much of an issue either.

Oh: And Ubuntu is a debian-knockoff but this is OpenSuSE which is a SuSE Enterprise knockoff and does not have (AFAIK) a "multi-arch" version. Plus the fact that Kumba builds the system in SuSE Studio which doesn't have any form of dual-build scenario.

[DomeDan]

I did state that its a G3 server and I'm pretty sure all Proliant G3 servers use 32bit address space. I mostly got Xeon 3.06GHz/FSB:533MHz/Cache:512KB processors.

Its not a big problem for me, I'm a hacker so I will figure out how to get around it of course, I'm originally on 3.1.15 but keep my system updated.
but Imagine when people want to try out vicibox on an old machine (as you and many other recommend people to do).
ditching the 32bit iso feels a bit drastical in my ears, but maybe I'm just old fashioned..

Just wanted to raise my voice for those who still use 32bit

[geoff3dmg]

I have a HP Prolient DL385 G1 (2006 build date) here an even that will run 64bit...

[DomeDan]

Ok thats just strange that they named it G1 because I got:
Proliant DL380 G1: Pentium3 1.0GHz from before 2002 at least http://www.harddrivesdirect.com/quicksp ... L380G1.php
Proliant DL320 G2: Pentium4 3.6GHz from 2004 http://h18004.www1.hp.com/products/quic ... ocid=11512
Proliant DL360 G3: Xeon 3.06GHz from 2004 http://h18004.www1.hp.com/products/quic ... ocid=11504

Xeon had a 64bit version called "Xeon MP" https://en.wikipedia.org/wiki/Xeon but I don't got that processor

[Kumba]

The issue is not that I can't build a 32-bit and 64-bit, it's that in SuSE Studio the project is defined as either 32-bit or 64-bit. So to have two builds I have to have two projects in Studio. The development usually ends up being done in one project and having to be transferred over to the other. Since there are no good tools to diff between the two projects or "clone" a project from one arch to another that leaves a lot of busy work. That's why I mentioned above that a chunk of my time is just making sure that the 32-bit version does what the 64-bit version does as well. It's also why some bugs are arch specific instead of being shared.

OpenSuSE is not really a knock-off of SuSE Enterprise like CentOS is to RedHat. It is more of a forward development version of SuSE Enterprise. So when SuSE wants to implement new features or tools in SuSE Enterprise, like btrfs or systemd, they implement it first in OpenSuSE for a release or two and then roll it back into SuSE Enterprise once they have it worked out and built up some confidence. The benefit of this is that usually after a few months OpenSuSE will be about as stable as SuSE Enterprise. The down side being is that there is only a 2 to 3 year maintenance window as opposed to 5 to 7 with SuSE Enterprise. It's also why I was waiting for OpenSuSE v.13.1 to mature for ViciBox v.6.0.

Debian and Ubuntu are an even more separated from each other then how SuSE/OpenSuSE and RedHad/CentOS are related. Ubuntu is more of a customized re-rolled distribution of Debian. They don't necessarily play well with each other like the two mentioned above and have differing design principles and goals.

[DefLeppard]

Is it too difficult to build a distro using the latest Ubuntu Server base?

[williamconley]

I did state that its a G3 server and I'm pretty sure all Proliant G3 servers use 32bit address space. I mostly got Xeon 3.06GHz/FSB:533MHz/Cache:512KB processors.

Um ... not trying to beat a dead horse, but you apparently are "unaware", so I'll see if this helps you in the future (I'm NOT picking on you ... honestly! )

G3 is a brand. Proliant G3 is the same brand with company name in front. Xeon is a "model family" and while providing the speed is at least slightly helpful, there are still hundreds of Xeon processors out there (in both 32 bit and 64 bit). No, not all G3s are 32-bit. I couldn't guess what percentage are 64-bit vs 32-bit, but I do know that "branding" does not help when trying to determine this sort of thing, which is why I asked about the Processor Model Number. If you ask the OS, it will ordinarily tell you (in the boot log, or in a /proc/ file related to the CPU ...) the actual model number of the processor. In many of our systems, this results in the processor ID:

Code: Select all

cat /proc/cpuinfo

"Model Name" will then give you something you can look up on the ark (ark.intel.com, or just google "ark xeon 7020" or something similar), luckily it's xeon and not amd. The definition of the processor will give you the instruction set (64 vs 32). In the case of the ark, that will also give you the compatible motherboards. If you check your G3 model you MAY find the motherboard (and verify that it will hold the CPU your system claims to have installed to validate your find ...). The motherboards, in turn, will give you a list of CPUs that are compatible. You may well find that there is a 64-bit CPU available for your system. Many are even in the older systems from when 64bit was new. The "highest end" processors would be a 64bit but very expensive back then. Now many of those processors can be under $50 and cause a serious increase in capacity.

To summarize: The actual model number of the CPU is the best thing to go by. Pull it out and look at it or use the command above to ask the server while it's running. You "Can" often find others with experience via the model number of the box it's in, but you can't go by the "G3" brand as that's not specific enough.

So if you research the full model of your system to get the Motherboard and see which Processors can be put in that box (and verify that the Processor already in the box falls in that list to be sure you're on the right track), you may find there is a 64-bit processor available for it. And it might even be cheap.

[williamconley]

Is it too difficult to build a distro using the latest Ubuntu Server base?

"too difficult" is subjective. More difficult than SuSe Studio? Yes. Kumba/Matt (someone over there) became increasingly displeased with the number of serious changes that would affect the ISO when they were using Ubuntu. So they jumped ship to SuSE and found a more stable base upon which to build. And apparently it was quite helpful that SuSE Studio was also available on this platform.

However, boybawang just (theoretically?) posted something regarding the latest Ubuntu ISO. I couldn't find the reference, but it was supposed to be there somewhere.

PoundTeam is also still poised to publish an Ubuntu ISO with Vicidial pre-installed (similar to Vicibox classic, but branded differently to avoid confusion over the publisher).

[mflorell]

The main reasons we abandoned Ubuntu as an ISO installer base was the poor maintenance of the server distro and the complexity(time it took) of creating a packaged ISO on Ubuntu. The problem was they would put out a new module, but wait a couple weeks to put out the source package for the module. Now this wasn't on some trivial component, this was on things like the Linux kernel. They would put out a new revision, but not update the kernel source for two weeks. During that two week period, if you did an update after installing the ISO, then none of the kernel components that relied on rebuilding the kernel from source would function(i.e. zaptel, Sangoma, etc...). This was consistently a problem, so when SuseStudio came out and made it easy to do a full ISO build in a few hours then we jumped on that platform. At that point we used OpenSuSE for our manual installations anyway, so it was an easy transition. It is also important to keep in mind that servers are not the primary focus of the Ubuntu project, desktops are, and the way they manage their project clearly shows that.

[Nefariousparity]

My only question, is why not CenOS? Thus far I'm happy with OpenSuse, just required me to find where somethings are located. Someone once told me to cluster with GoAutoDial because it runs CentOS. They said, "Do you see any enterprise systems running OpenSuse"

I am more familiar with CentOS.

Long story short? Why don't you guys use CentOS?

[mflorell]

We've posted about the issues with the whole redhat family(including CentOS) of distros several times before. The basic summary is:
- not designed for high-performance(kernel defaults to "desktop")
- measurably higher load for the same tasks
- errors in builds on standard packages like Perl
- non-standard binutils
- buggy and inconsistent package management
- forced backporting of kernel modules to preserve very old Linux kernels, leading to more system instability

SuSE enterprise is used in enterprise installations around the world. It is the one Linux distro aside from RedHat that almost all hardware providers support drivers for. It is commercially supported.

We have fixed problem CentOS Vicidial systems that crashed on a daily basis by simply wiping out the install and using OpenSuSE. The crashes stopped and the system ran better.

Don't believe us? Ask Oracle what they thought of RedHat. They were so frustrated working with it that they created their own distro.

[williamconley]

On that note, we have NO CentOS based clusters. Single servers only. We still have one or two (very old) Ubuntu-based clusters. The rest of the major systems (enterprise/clusters, call them what you will) are all OpenSuSE.

[Nefariousparity]

Wow! Thanks for the prompt response. I will continue to use VIciBox for Clustering. Support right out the box! Sorry I missed the party on all of that.