Results 1 to 2 of 2
Enjoy an ad free experience by logging in. Not a member yet? Register.
- Join Date
- Jan 2011
How to map or mount the whole developing environment remotely?
I've got a problem about how to map or mount the whole developing environment remotely?
There is a server A (CentOS) which I have got a normal user name and password but no root control.
And my desktop B (Opensuse) which I've got the root authority.
Normally, when I do some software developing, I use SSH to login to A. All the developing environment are installed on A, e.g. libraries, PATH, makefile, etc.
However, there is a waste of my machine B, because all the test, debugging are performed on A.
I know that sshfs can map a path to local remotely. May I ask if there is a method to map or mount the whole working environment from A to B please?
Any tips would be appreciate! Thanks very much.
- Join Date
- Apr 2009
- I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
Well, this can be done, but whether or not it will be productive for you depends upon the versions of CentOS and Suse, since there are a lot of little niggling differences in library versions, header files, etc. In any case, if you can get your sysadmin on the CentOS machine to export your home/development directory so your OpenSuse desktop can mount it, then this isn't a problem so much. In fact, in the company I used to work for we configured our development environment much in this way so that we could easilty do cross-platform/cross-version development. Wherever we logged in, we had the same home directory, which was installed on a disc farm somewhere in ITlandia. So, I could work from my desktop, build and test some software, remote login to another machine, rebuild and test in the new environment, switch to another... In our case, some of the systems (all Unix at that time - no Linux) were HP's (HPUX 8, 9, 10, 11), some DEC's (Ultrix and Tru64), some IBM's (AIX), some Sun (SunOS or Solaris), and some NEC (system V on Intel). In my case, I could open a terminal window on all of the build/test systems, have the same home environment, and build/test on each (not at the same time of course) and see what the unit tests said about compatibility. And this was for a major enterprise manufacturing system that consisted of millions of lines of code. Since I was responsible for the development framework, I would build/test the framework (only 10's of thousands of lines of C++ code), but after that passed, I had to build and unit test all the major system components that depended upon the framework to see where things broke, as they inevitably do.
With some directory twiddling, I could have built all the platforms at the same time from the same source base, but having done that I decided that being methodically serial in some instances was better from the clarity perspective. As a result, my reported bug count was just about zero for almost 20 years. That way I was able to invent neat new technologies that kept us ahead of the competition and was rewarded with nice stock options every year or two.Sometimes, real fast is almost as good as real time.
Just remember, Semper Gumbi - always be flexible!