2 ms·

> RedHat 7 is stuck on GCC 4.8 If you are actually maintaining a large C++ codebase and all your workstations are required to run RedHat 7 for some reason, you

by saurik 5y ago

> RedHat 7 is stuck on GCC 4.8 If you are actually maintaining a large C++ codebase and all your workstations are required to run RedHat 7 for some reason, you download a newer version of GCC and run it on RedHat 7. RedHat 7 is not "stuck on" GCC 4.8. (And I don't just mean that "you can get newer official compiler packages from RedHat and you just don't know it", like the other reply says: you can install a new version of GCC even if that weren't the case.) And in case anyone's mind goes here: newer versions of GCC aren't incapable of generating binaries that run on older systems, either; a large number of my users are using CentOS 6 (yes: 6) and I use the latest bleeding edge compiler to compile my code. (The secret--which I assure you most of the people who do extensive maintenance work knows--is you always "cross-compile" your binaries for Linux, even if you are on Linux already, so you have complete control over the deployment glibc version.)

pjmlp 5y ago
In most enterprises you don't download anything if you want to keep your job. Additionally, exactly to prevent the clever ones that still do it anyway, Developers get their own group id and HOME is mounted as no exec. Naturally I am speaking about typical UNIX shops were contractors get to SSH into the official development boxes.
- saurik 5y ago
  I mean, good luck building typical Unix projects in a directory mounted non-executable... having build steps that generate binaries that build other binaries is like, "the name of the game". Is this your experience, or are you just surmising this? If the former, how did that even work? In my long experience (which has included working on embedded systems for a large highly-boring multinational company: Bosch) it is more likely that the organization will literally vendor the compiler--which is the best strategy for making sure that your code will still be compilable forever--than insist that their engineers not be able to run code on their laptop (though they certainly had extremely tight control over networking and data movement).
  - pjmlp 5y ago
    Yes, that was my experience back when stuff like HP-UX, Aix and Solaris was commonly deployed. There is no laptop to run code on, laptop is only for SSH and X Windows server, or cloud shell in modern "mainframes". Nowadays one can make it one level up my having a CI/CD wall between the development environment and the actual stages, thus whatever one uses to develop must also be available on the stages, which contractors can only access with the help of hands from internal employees.

by saurik 5y ago

pjmlp 5y ago

In most enterprises you don't download anything if you want to keep your job. Additionally, exactly to prevent the clever ones that still do it anyway, Developers get their own group id and HOME is mounted as no exec. Naturally I am speaking about typical UNIX shops were contractors get to SSH into the official development boxes.

saurik 5y ago
I mean, good luck building typical Unix projects in a directory mounted non-executable... having build steps that generate binaries that build other binaries is like, "the name of the game". Is this your experience, or are you just surmising this? If the former, how did that even work? In my long experience (which has included working on embedded systems for a large highly-boring multinational company: Bosch) it is more likely that the organization will literally vendor the compiler--which is the best strategy for making sure that your code will still be compilable forever--than insist that their engineers not be able to run code on their laptop (though they certainly had extremely tight control over networking and data movement).
- pjmlp 5y ago
  Yes, that was my experience back when stuff like HP-UX, Aix and Solaris was commonly deployed. There is no laptop to run code on, laptop is only for SSH and X Windows server, or cloud shell in modern "mainframes". Nowadays one can make it one level up my having a CI/CD wall between the development environment and the actual stages, thus whatever one uses to develop must also be available on the stages, which contractors can only access with the help of hands from internal employees.