Please explain why it would be better to log into Windiows and then immediately start up a VM - do all the work in the VM and once finished with the VM then shut down windows - as compared to simply running native Linux in the first place.
An infinite amount of different environments separate from the host os. Installing things on vm has no risk of hosing the the host machine. Where as installing things on the host always has a potential to break the os. Also you eliminate the risk of one project inadvertently affecting another by using separate boxes per project.
[quote=âoddz, post:22, topic:211077â]
An infinite amount of different environments separate from the host os. [/quote]
I only need one
If I spend 100% of the time in the one VM then that effectively is the host machine
So what you are saying is that if I set up my host machine with a single VM and spend 100% of the time in that VM and do noting else on the host that if the VM is hosed that it will not affect me still being able to use that VM 100% of the time. That doesnât sound right - if everything I did was in a VM and the VM was hosed it would be no different from the OS being hosed.
Since I run duplicate copies of the OS (so restoring a hosed OS is not a problem) not using a VM saves me the overhead of running a VM.
Arenât you supposed to be using Apacheâs httpd-vhosts.conf for this? Make a default root directory, letâs call it default. Stuff your original default project in this directory. Create multiple projects using httpd-vhosts.conf and creating their respective directories in your PHP environment. Then just separate them with their respective directories.
This saves you time and resources. From my experience, VMs still use up some of the hostâs space. Spaces donât just magically come out of no where. You have to give it some space from the host. IIRC, max is 25 GB and lowest is 4 MB. So that space is still being taken out of the host. Thatâs why I honestly think my VMs lag a lot because spaces are being split between VMs and therefore since the VMs are being hosted on the original host, the original host doesnât have enough space to do itâs regular routine.
If the main idea is to keep your work space separate from your host so you donât screw up your host then why are you fighting against XAMPP? XAMPP has a portable version which allows you to have an environment separate from the host. So if you screw up a part of your environment, you only screwed up a $7 - $15 USB stick. You can also install Ruby via XAMPP if you want as well. You donât have to use PHP if you donât want to. Plus, as I said before, VMs lag for me, but if I have XAMPP and I use USB, it wonât lag so bad and I will be saving 3 hours of lag fix.
You lost me with this question. Are you running Linux natively? If yes, then why were you asking about .dlls?
Even if you are running Linux natively,
- Do you use any kind of support software for development? CI software? Node for JS code? Profilers. Benchmark suites. Etc?
- While you were messing around with PHP7, what happened to your current development environment? Can you simply go back to using it? Or do you have to revert changes you made to get back to the way things were?
- Have you ever fiddled with other software for development or for other purposes and had to revert back all the changes?
- If you get a different client, who uses CentOS instead of Ubuntu, would you feel more confident to have built a very similar system and developed on it, then had you built your system on another OS?
You donât do all the work in the VM. That is the beauty of the dev environment with a VM. You do all the work on your host machine. You only save your work to the VM and test it there. With any halfways decent IDE, the saving of your work can happen automatically too. And actually, if you are using Virtualbox (and I am sure it is the same for other virtualization systems), you can create shared folders too. However, this has a couple of disadvantages, like slowing I/O for testing and dynamically built files not syncâing back to the host machine.
Scott
True with a standard vm but not with puphpet. Also if youâre using the optimal file sync read and write operations are just as fast as working directly on the host machine.
Obviously. VMs have to get resources from somewhere.
If you have a host that is too small (not enough RAM), then yes, you might have problems. As for âregular routineâ, if you are working with a VM, then you should only be doing development work and these applications donât take up that much on resources to run. So, I am not sure what your argument here is.
The lagging on the VM might be because of the shared folder. Try SFTPing into the VM instead of using a shared folder and see if the VM is faster.
Scott
Swap two folder names and comment two lines in a config file and uncomment two others and then restart apache. Admittedly three steps for PHP compared to two step for mySQL (which doesnât need any lines commented or uncommented). Still only a few seconds to switch them though.
Anyway the I opened this thread to resolve was with PHP 5.6 and PHP 7 not running the mysqli extension when I first tried to run them. Since the issue was independent of the PHP version it could presumably also have been independent of the operating system so it is just as likely Iâd have had the same problem with a VM or any of the other alternatives that have been suggested. For both versions renaming the php_mysqli file to something else and then renaming it back is what appears to have fixed the problem (no idea why but thatâs what fixed it for both 5.6 and 7)
With Virtualbox you would have your regular dev VM ready and waiting and untouched. Your tests with PHP7 would be done in another VM. Donât like what you did or the results? Then just destroy the VM. Takes two clicks.
Scott
Saving me perhaps 10 seconds. Anyway I solved my problem and no one has suggested any alternative that would definitely have avoided my having the problem so I am happy to continue using the same development environment (now upgraded) as I have been using for the past few years.
Switching to an alternative would have involved extra time to learn how the alternative worked AND would probably have given me the exact same problems with mysqli as I had anyway - and so would have added hours to the time it took meâŚ
What happens when you need to fix a critical bug and the upgrade / testing on migrating to php 7 isnât complete. Are you going to down grade to php 5.x.
The systems havenât had any critical bugs in the last 12 years so I donât expect one to suddenly turn up now. So far since I fixed the couple of warning messages that upgrading from PHP 5.3 to PHP 5.6 produced I havenât found any other issues at all. With those few warnings as exceptions all the code seems to run identically on PHP 5.3, PHP 5.6 and PHP 7.
If I do need to revert back I can do so in under 30 seconds just by sapping a couple of folders and restarting apache.
Of course once the system grows to the point where I need to employ someone to help me maintain it then having multiple test environments available will become useful - just running in a VM is overkill for my current needs - and has nothing to do with the original problem I was asking for help with that was independent of PHP version and where it was being run.
Oh, one of the other advantages to using a VM with Linux is finding answers to problems faster, because Linux powers a lot more servers than Windows does. 
But, if you only program for one system and you are alone doing it, then yes, it would seem the effort to work with virtualization is a bit of overkill.
Scott
I see Its been a long time since I worked on a small code base.
This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.