Nico Kadel-Garcia wrote on 2/22/17 1:05 AM:
> On Tue, Feb 21, 2017 at 3:58 AM, MAH Maccallum
> <[log in to unmask]> wrote:
>> Thanks, Christoph-Erdman. I managed to resolve the problem by
>> uninstalling a Windows program that was, I think, causing the
>> issue by trying to access the Linux partition, so I am back in action,
>> but your information will certainly help avoid such issues in future.
>> Thanks again, Malcolm
> Note to the wary. The simpler solution, for the future, is not to use
> dual-boot. Virtualize one OS inside the other, and don't expose one
> system's disks to the other.except over more regulated, network based
> file sharing. I admit that, these days, I'll use Windoes as the base
> OS for better support from my hardware vendor and better game
> performance, and use VirtualBox or other virtualization systems for
> running lighter weight Linux VM's. for testable research and
> development on my laptop or desktop. I don't get the full speed of the
> the hardare for my Linux VM's, but they're so much lighter weight I
> don't usually *care*, and I can still run my games and critical
> Windows apps.
>
> And yes, I've run critical debugging tools and penetration tools from
> my Linux VM, on an encrypted disk for basic security in the admittedly
> tougher to secure Windows environment, and even run PXE, DNS backup
> servers, and internal Scientific Linux yum mirrors on VM's on my
> laptop for debugging and network services as needed. And it's been mch
> easier to debug or repair a broken VM than an unbootable dual-boot
> setup.
>
> I'm not discounting dual-boot solutions for bare metal speed or
> debugging hardware driver compatibility, but I don't see a lot of
> point to it these days.
When VMware Workstation 3 came out over 15 years ago, I totally stopped
supporting dual-boot on my users'
computers and highly encouraged them to use VMware. When informed that they
could share files between their
Windows host and the linux VM in real time, it became a no-brainer. We had a
license for multiple systems, so all they
had to do was grab it from our local software repo and install it. Life became
so much easier.
If you are looking for a significant improvement in performance over a VM, you
can go the container route and install
Docker for windows (https://docs.docker.com/docker-for-windows/). However, that
just gives you a command
line interface (CLI).
On a linux host running Docker, you can run a windows manager in the Docker
container.
See here: https://csicar.github.io/docker/window-manger/2016/05/24/docker-wm.html
How to do that on a Windows host, I don't know - never went there.
Docker images start up exceedingly fast (in a couple of seconds) and performance
is almost as fast as
the native hardware (be it windows, mac, or linux based), whereas, as Nico
points out, running a VM is much
slower in performance than the native host.
It's not for everyone, but if you need native host performance, it's something
to try. Most folks are familiar with VMs,
so there's a bit of a learning curve with Docker and its terminology and syntax,
plus you may run into unforeseen gotchas
with Docker. I, personally, have not used Docker on Windows or a Mac - just on
linux.
You don't have to build a linux OS with Docker (as with a VM, although you can
download pre-built VMs) - you just
download a pre-built container from the public Docker hub of whatever distro
you'd like, be it Ubuntu, CentOS, etc.
But the container is ephemeral, so if you make changes to it (add/update
software), you need to issue a "docker commit"
command after exiting the container, otherwise any changes vanish.
You can build your own, which is what I had to do last summer when I needed an
SL6.x container and none were to
be found on the Docker hub - just latest 7.x releases of CentOS. There were some
CentOS 6.x containers, but they were
special use cases built by individuals and not approved by Docker for general
use and were not being updated to stay
current. And who knows what goofy or weird software or setups were in them.
After building my own, based entirely on
the host SL6.x system where I had Docker installed, I then needed to upload my
SL6.x container to the public Docker hub
repository, as setting up your own container repository is significantly non
trivial. Meaning, I could then go to any linux
system with Docker installed and download (pull) my SL6.x container and run it
as is.
Caveat: I'm retied now, so I haven't worked with Docker since last summer and
haven't kept up with any new changes
or features. And as always, your mileage may vary...
Just another option...
- Larry
--
P. Larry Nelson (217-693-7418) | IT Administrator Emeritus
810 Ventura Rd. | High Energy Physics Group
Champaign, IL 61820 | Physics Dept., Univ. of Ill.
MailTo: [log in to unmask] | http://hep.physics.illinois.edu/home/lnelson/
------------------------------------------------------------------------------
"Information without accountability is just noise." - P.L. Nelson
|