Now to test the websites I use multiple virtual machines (VirtualBox) with Web browsers.
I want to make portable versions of browsers (to collect IE, Opera, Safari, FF, Chrome and maybe another). I want that browser have development tool (e.g. like Firebug).
For virtualization apps I found several solutions:
BoxedApp
Cameyo
JauntePE
Spoon Studio / Xenocode Virtual Application Studio
VMware ThinApp
MoleBox Virtualization Solution
Tell me what there are and what should I choose for my task?
As far as I know, if to use boxedapp, your an application will run properly even if it doesn't have the right to write to the system registry.
I personally use VMWare Workstation. It has never given me problems. I'd recommend it.
In terms of what there is available out there, there is a ridiculous amount of programs to choose from.
There are my two cents! Hope this helps and good luck!
Can you please clarify what you are asking?
The assumption made by Jebego, and my understanding of your question, is that you are interesting in finding out what different Virtualization tools are available, though your comment:
I want to assemble a collection of browsers for testing as portable application. In addition to its main functions I want to be able to see html \ css \ js or something like Firebug.
Is slightly misleading as it refers to browsers.
Other useful information you may want to include is the size of your budget. You mention that you are currently using VirtualBox, which is Open Source, so I am assuming you ideally are looking for products which are free.
Anyway assuming my assumptions are correct, I can give details on a couple of options which I have experience with:
Micsoroft Virtual PC - I found Microsoft Virtual PC easy to set up and get started with. It is a free download, and if you have Windows 7 installed then I believe it is built into the OS. If you're looking for seomthing fairly basic, simply to run your application in a browser for testing purposes then this may be sufficient. Virtual PC allows you to allocate a specfic amount of RAM to each VM, but you cannot go over 3,712MB, which is pretty limiting if you need to do anything requiring significant resources inside the VM.
VMWare Server - I recently moved to VMWare Server 2.0, also a free product. I use a virtual machine for development tasks, and found that the RAM limit on Virtual PC was too low to run the developer tools and add-ins at a suitable speed. With VMWare Server, you can allocate as much RAM as you see fit (obviously you need to have it available in the host machine), and you can also specify the number of CPUs to allocate to the VM. The setup is slightly less starightforward than Virtual PC, but by no means complicated. The tools provided by VMWare offer more configuration options (such as those mentioned above).
This is a brief summary of my experience, I'd be happy to give more detail on either if you so require.
Some general things to bear in mind when choosing virtualisation software:
What OS do you plan to install on the guest? Some Virtualisation software is better suited to specific OS'es
How much poower do you need inside your guest VM? Again, this will influence your decision on which way to go.
Hope this helped, good luck with your search.
Related
I've built a program via MS Access 2007 that I distribute via Microsoft Access Runtime. My clients do not have Access. Recently I've received multiple request for the application to be available for Mac. The volume of requests is low enough that it's not economical to rebuild the entire program in another language.
What would be the most economical method of allowing users to use the software on a Mac?
Is LibreOffice or Wine an option in this case, or is the only option for the user to purchase Windows and use a virtual environment?
LibreOffice Base: Extremely unlikely. Even if you were to get Base to connect to the Access tables it almost certainly would not be able to use the Access forms, reports, macros, VBA code, etc..
Wine: Worth a try, but I wouldn't be at all surprised if there were issues, quite possibly serious ones. According to the WineHQ page here, Access 2010 gets a "Bronze" compatibility rating, meaning
Application works, but it has some issues, even for normal use; a game may not redraw properly or display fonts in wrong colours, be much slower than it should etc.
That same page lists "Visual Basic" as one of the things that did not work under Wine when it was last tested.
If I were you I would give the latest version of Wine a quick try to see if things have improved but I wouldn't spend more than a couple of hours tinkering with it. I suspect that a Virtual Machine running an actual copy of Windows is probably the only real option in this case.
I am experimenting with different open source projects just to see which one I can work with since I am a beginner. Of course, many projects have different dependencies and programs that you must install. I want to keep things organized and I don't want to pollute my main windows account, since I use this machine for everyday computing also.
Will creating a seperate windows account on my computer help separate the dependencies for the projects? Are there any better alternatives (other than using virtual machines)?
Thanks
Although you mentioned other than them, but virtual machines are actually the best option if you're planning on working with a lot of different projects and you don't want to pollute your environment too much. If you build them right, you can have a baseline VM that is simple to revert back to if you want to start from scratch because the environment got too polluted.
The problem with only using a separate account is that many installable tools and libraries means they're still going to be made available for all users on the machine, so it doesn't keep things cleaned up. For example, if Visual Studio tools typically apply to all users on the machine. COM dependencies aren't user specific. Some things install Windows Services that need to be running most of the time, but you don't use unless you're developing for them (like SQL Server Reporting Services).
How about installing many kinds of operation system?
If you have enough money, you can buy a computer only for experiment
Virtual machines is definitely the way to go - most non-trivial software modifies more than HKEY_CURRENT_USER machine state. If you don't want full-blown virtual machines (but oh, they're sweet, especially the ones supporting state snapshots!) you could look at something like sandboxie.
Is there any reason in particular why it's recommended to run memcached on a Linux server? Is it really that bad an idea to run it on a Windows Server box? What about an OS X Server box?
The biggest reason that I read is about TCO. In other words, for each windows box that we run memcached on, we have to buy a copy of Windows Server and those costs add up. The thing is that we have several servers that have older processors but a lot of RAM - perfect for memcached use. All of these boxes already have Windows Server 2003 installed on them, so there's not really much savings to installing Linux. Are there any other compelling reasons to use Linux?
This question is really "what are the advantages of Linux as a server platform" I'll give a few of the standard answers:
Easier to administer remotely (no need for RDP, etc.) Everything can be scripted or done via CLI.
Distributions like the Ubuntu LTS (Long Term Support) versions guarantee security updates for years with zero software cost. Updates can easily be installed via command line, and generally don't require a reboot.
Higher performance. Linux is generally considered to offer "more bang for the buck" on a given piece of hardware. This is generally due to lower resource requirements.
Lower resource requirements. Linux runs just great on 256MB or less of RAM, and on very small CPUs
Breadth of available software & utilities.
It's free. (As in beer)
It's free. (As in freedom) This means you can see, change, and file bugs against the code you're running, and talk directly with the developers.
Remember, that TCO includes the amount of time that you (the administrator) are spending to maintain the machine. Linux has a lower TCO because it's easier to maintain, and you can spend your time doing something other than administering a server...
Almost all of the FAQs and HOWTOs are written from Linux point of view. Memcache was originally created only for Linux, the ports came later. There is port to Windows, but it's not yet in the official memcache distribution. Memcache on Windows is still guerrilla style. For example there is no memcache for x64 Windows.
As of memcache on MacOS X on servers: niche of niche of niche.
There doesn't seem to be any technical disadvantage to running it in windows. It's mainly a cost thing. If the licenses are just sitting around unused, there's probably no disadvantage at all. I do recall problems on older windows with memory leaks in older windows APIs, particularly the TCP stuff -- but presumably that stuff is all fixed in modern windows.
If you are deploying memcached you probably have a fairly significant infrastructure (many, many machines already deployed). Even if you are dedicating new machines to memcached, you'll want to run some other software on them for system management, monitoring, hardware support etc. This software may be customised by your team for your infrastructure.
Therefore, your OS platform choice will be guided by what your operations team and hardware vendor will support for use in production.
The cost of a few Windows licences is probably fairly immaterial and you probably have a bulk subscription already - in fact the servers may be ordered with Windows licences already on them.
Having said that, you will definitely want a 64-bit OS if you're running memcached - using a 32-bit OS is not clever and will mean that most of your RAM cannot be used (you'll be limited to around 3G depending on the OS).
I'm assuming that if you're deploying memcached, you'll be doing so on hardware with LOTS of ram - it's pretty pointless otherwise, after all.
I am trying to perform a fair comparison of XenServer vs ESX and one comparison I would like to make is performance with multiple VMs. Does anyone know how to go about benchmarking VM performance in a fair way?
On each server I would like to run a fixed number of XP/Vista VMs (for example 8) and have some measure of how quickly each one runs when under load. Ideally I would like some benchmark of the overall system (CPU/Memory/Disk/Network) rather than just one aspect.
It seems to me this is actually a very tricky thing to do and obtain any meaningful results so would be grateful for any suggestions!
I would also be interested to see any existing reports or comparisons that have been published (preferably independent rather than vendor biased!)
As a general answer, VMware (together with other virtualization vendors in the SPEC Virtualization sub-committee) has put together a hypervisor benchmarking suite called VMmark that is available for download. The VMmark website discusses why this benchmark may be useful for comparing hypervisors, including an FAQ and a whitepaper describing the benchmark.
That said, if you are looking for something very specific (e.g., how will it perform under your workload), you may have to roll your own variants of VMmark, especially if you are not trying to do the sorts of things that VMmark benchmarks (e.g., web servers, database servers, file servers, etc.) Nonetheless, the methodology behind its development should be of interest.
Disclaimer: I work for VMware, though not on VMmark.
I don't see why you can't use common benchmarks inside the VMs: WinSAT, Passmark, Futuremark, SiSoftware, etc... Host the VMs over different hosts and see how it goes.
As an aside, benchmarks that don't closely match your intended usage may actually hinder your evaluation. Depending on the importance of getting this right, you may have to build-your-own to make it relevant.
Why do you want to bench?
How about some anecdotal evidence?
I'm going to assume this is a test environment, because you're wanting to benchmark on XP/Vista. Please correct me if I'm wrong.
My current test environment is about 20 VMs with varying OS's (2000/XP/Vista/Vista64/Server 2008/Server 2003) in different configurations on a Dual Quad Core Xeon machine with 8Gb RAM (looking to upgrade to 16Gb soon) and the slowest machines of all are Vista primarily due to heavy disk access (this is even with Windows Defender disabled)
Recommendations
- Hardware RAID. Too painful to run Vista VMs otherwise.
- More RAM.
If you're benchmarking and looking to run Vista VMs, I would suggest putting your focus on benchmarking disk access. If there are going to be performance differences elsewhere I doubt they would be of anything significant.
I recently came across VMware's ESX Performance documentation - http://www.vmware.com/pdf/VI3.5_Performance.pdf. There is quite a bit in there on improving performance and benchmarking.
The Free MS Windows replacement operating system ReactOS has just released a new version. They have a large and active development team.
Have you tried your software with it yet?
if so what is your recommendation?
Is it time to start investigating it as a serious Windows replacement?
Targeting ReactOS specifically is a bit too narrow IMO -- perhaps a better focus is to target compatibility with WINE. Because ReactOS shares so many of its usermode DLLs with WINE, targeting WINE should result in the app running just fine on ReactOS.
Of course, there will always be things that WINE can't emulate well (hence the need for ReactOS). In this way, it seems that if something runs in WINE, it will run in ReactOS, whereas the fact that something runs in ReactOS doesn't mean that it will necessarily run in WINE.
Targeting WINE is well documented, perhaps easier to test, and by definition, should make your app compatible with ReactOS as a matter of course. In this way, you're not only gathering the rather large user base of current WINE users, but you're future-proofing yourself for whenever anyone wants to use your app with ReactOS.
In their homepage, at the Tour you can see a partial list of office, tools and games that already run OK (or more or less) at ReactOS. If you subscribe to the newsletter, you'll receive info about much more - for instance, I was quite surprised when I read most SQL Server 2000 tools actually work on ReactOS!! Query Analyzer, OSQL and Books Online work fine, Enterprise Manager and Profiler are buggy and the DBMS won't work at all.
At a former workplace (an all MS shop) we investigated seriously into it as a way to reduce our expenditure in licenses whilst keeping our in-house developed apps. Since it couldn't run MSDE fine, we had to abandon the project - hope in the future this will be solved and my ex-coworkers can push it again.
These announcements might as well be also on their homepage - I couldn't find them after 5 mins. of searching, though. Probably the easiest way to know all these compatibility issues is to join the newsletter, or look for its archives.
I have been tracking this OS' progress for quite some time. I believe it has all the potential to really bring an OSS operating system to the masses for it breaks the "chicken and egg" problem: it has applications and drivers from the very beginning (since it aims to have full ABI compatibility with MS Windows).
Just wait for their first beta, I won't be surprised if they surpass Linux in popularity really soon after that...
Post Edit: Found it! Look at section Support Database, it's the web place to go look for whether a particular piece of hardware of some program works on ReactOS.
ReactOS has been under development for a long long time.
They were in some hot water earlier because some of their code appeared to be line by line dissasembly of some NT kernel code, I think they have replaced all of it.
I wouldn't bother with cross platform testing until they hit the same market penetration as Linux, which I would wager is never.
Until ReactOS doesn't randomly crash just sitting there within 5 minutes of booting, I won't worry about testing my code on it. Don't get me wrong, I like ReactOS, but it's just not stable enough for any meaningful testing yet!
No, I do not think it is time to start thinking of it as a Windows replacement.
As the site states, it's still in the Alpha stages. More importantly, whos Windows replacement? Yours? Your users? The former is one thing, the latter is categorically a no-go.
As an aside, I'm not really sure who this OS is targetting. It has to be people who rely on Windows software but don't want to pay, because people who simply don't want Windows can use MacOS / Linux, and the support (community or otherwise) for these choices is good.
Moreover, if you use Linux you already have some amounts of Windows software support via Wine.
Back to people who rely on Windows software but don't want to pay. If they are home users they can just simply pirate it, if they are large business users they already have support contracts and trained people etc. It's hard enough for large businesses to be OK to update to new versions of Windows, let alone an open source replacement.
So I suppose that leaves small businesses who don't want to obtain illegal copies of MS software, can't afford the OS licences and rely on software that only runs on Windows and has bad of non-existent Wine compatibility.
It is a useful replacement for Windows when it runs 'your' software without crashing. At the moment it is not a general purpose os as it is too unstable (being only alpha) but people have used ReactOS successfully in anger for specific tasks already. As a windows replacement it has multiple potential uses, sandbox systems, test and development systems, multiple virtual instances, embedded devices, even packaging/bundling legacy apps with their own compatible o/s. Driver and application compatibility, freed from Microsoft's policy of planned obsolescence and regular GUI renewal, what's not to like?