On 2016-05-23 20:12, Andrey Semashev wrote:
On Monday, 23 May 2016 12:52:17 MSK Vladimir Batov wrote:
On 05/23/2016 06:09 AM, Andrey Semashev wrote:
Actually, Ubuntu is quite proactive. The latest release is 16.04 (which is also an LTS release) provides gcc 5.3.1 out of the box. Also, there is PPA[1] which provides more recent compiler versions.
Actually, it's the customers who are not in a hurry to install and "play" with "latest and greatest" for obvious reasons. Unlike children who are eager to play with a new "toy" and throwing tantrums when the rest of the world is not catching up, businesses always (from my experience) a version behind... be that MS Windows or Ubuntu LTS or Solaris.
I was addressing the remark with regard to Ubuntu, which is obviously not to blame for your customers' preferences.
Please do not get me wrong. I was not arguing, disputing, correcting your point. IMO Ubuntu is doing quite an acceptable job. I merely tried to highlight that Ubuntu (or any other OS developer) are not the root cause why many developers are still on older compilers.
Then, there are different kinds of customers. In some cases it doesn't really matter what OS your software is developed for - because you ship both the software and the OS. Sometimes hardware, too.
True. I personally have been overwhelmingly working for large companies delivering only s/w for their established IT infrastructure. In that setting what I can use for development and ultimately deliver are driven by that corporate IT infrastructure.
But I know what you're talking about. Corporate clients don't care how the software is written as long as it gets the job done. Developers do. So it's up to the developers to push for the new language features, libraries and so on.
:-) It's not my experience. Large corporations expect your software to just fit in to their IT infrastructure. Pushing or advocating for those corporations to change/modify their framework is most likely a wasted effort. An example. Up until fairly recently our customer (a big airline) was using Interix! That was their choice, already-made investment, etc. No amount of our effort was able to have them to allocate funds and move off it... So, our s/w had to compile with gcc-3.3 (hello C++14-only). Only when Microsoft dropped Interix and stopped support, they moved off Interix. Hooray!
In my practice language or library updates never came from top down in a company, always from bottom up from the initiative developers who care.
Well, I guess, you are luckier. :-) For us, the customer IT infrastructure is essentially carved in stone. We are free to do whatever we want... as long as it installs and works on their platform. So, the closer my development framework to their framework, the less hassle I have maintenance and support-wise.
My understanding is that rushing forward well ahead of the installed customer base causes a lot of headache as I'll then have to ship libraries not present on the customer machine. Then I'll have to make sure those correct libraries are in fact used... and fix when the customer screws something up (like LD_LIBRARY_PATH). So, simple "ship-and-forget" turns into maintenance and support on site. A nightmare.
Don't forget that using the older tools becomes more expensive over time - sometimes more expensive than maintaining your own up to date environment in the older OS.
Understood. But I am not talking old-old-old. It's just that big customers are always a version behind. So, right now, in my view, talking C++14-only and stuff is sheer nonsense.
And with regard to maintenance, the support contract is another (often significant, often main) source of income.
Indeed. The difference is mnt/support of your s/w as opposed as opposed to mnt/support of their platform and their environment. The more components I deliver (say, due to using libs missing in their standard installation) the more vulnerable I am to their tinkering with the system. Nothing new... I am sure you are well aware of all that. It's just that that aggravated persistent noise about C++14-only... loudly claiming to represent "wider C++ community" when in fact, it could not be further from the truth. Irritating.