I need to setup docker on my windows 10 OS. I've previously been a linux guy where everything just works so this is a pain for me. It works as expected but within the dockerfile there are calls that uses /bin/bash which makes the build fail.
I've tried to setup a VM with hyper-v but then i stopped because i figured there must be an easier way. I found the bash.exe in windows. i can't run as sudo but i guess that doesn't matter here as long as i run bash as administrator. wget works here but the docker program cant be found when i run docker --version.
Is the easiest way to run bash scripts on win10 with the bash.exe? And why can't docker run in the bash terminal (there is no .bashrc)?
I would use Linux on the Windows box. The two systems can access each other's file systems (\\wsl$, /mnt/c). I use Ubuntu, and it's as if I was using a "normal" Ubuntu box in all aspects, so far. I'd be surprised if your process didn't work here.
Alternatively, there's Cygwin. When running Cygwin, you're kinda in a VM, kinda not. It's a bit blurry. As such, it's not as robust as WSL. But it might do the trick, and it's a lot less "heavy" than installing a full Linux distro.
I am running a Xen server and I would like to debug the QEMU process. However, I don't want to run the QEMU process standalone, but I want it to run to back my domU.
How can I run and debug QEMU in this situation?
This answer describes two possible approaches. Hope somebody else can share more ways to do it.
Preliminary note: to have a debug-friendly build of QEMU, use the --enable-debug config option.
Debugging QEMU under Xen is a bit peculiar because of the integration between the hypervisor and QEMU. If you don't want to run QEMU standalone (no acceleration), the only choice under Xen is to use Xen as accelerator, as KVM will not work.
To do so, I don't think it's possible to manually run QEMU from the command line, but you have to let Xen start the process when the domU is launched. You can then use one of the following two options:
start your VM via Xen (xl create ...), then use gdb via command line attaching it to the QEMU process that Xen has started;
change device_model_override in the Xen configuration of the VM to point to a script that contains something like exec gdbserver :1234 /path/to/qemu $# - then you can start the VM like above (via Xen) and use target remote :123" in gdb to attach to the debugging session.
Option number 2 is particularly useful when looking at a crash that happens early in the startup if xl create -p ... doesn't help because it crashes whether the Xen VM is running or paused. It is also useful if you want to pass extra environment variables to QEMU. This is sometimes also useful in debugging.
Your script could look like the following:
#!/bin/bash
QEMU_LOG=/var/log/xen/qemu-log-debug.log # custom log file
export SSLKEYLOGFILE=/tmp/qemu-debug-ssl-key.log # extra env vars
export GNUTLS_DEBUG_LEVEL=4 # extra env vars
export XEN_QEMU_CONSOLE_LIMIT=0 # extra env vars
exec gdbserver 0.0.0.0:1234 /path/to/qemu-xen/qemu-system-i386 $# &> "$QEMU_LOG"
I just installed Git SCM on my Windows machine. My machine had Node installed earlier. I am able to use node -v in git bash. But, Why I am able to use windows applications inside Git Bash and not in WSL Bash.
Inside WSL Bash-
hello#comp:~$ node -v
Command 'node' not found, but can be installed with:
sudo apt install nodejs
Inside Git Bash-
hello#comp MINGW64
$ node -v
v12.10.0
WSL is an a Linux like compatibility layer. You run Linux applications on top of WSL and they think they are running natively on Linux while the system calls are being translated to Windows OS system calls (WSL2 -- not yet released -- is a full Linux kernel running inside Windows). You do get to access Windows files through /mnt/c/... but that's about all you can expect in terms of Windows-Linux interoperability.
Git-bash, on the other hand, is a Windows app -- a shell running windows applications. Some of these may be compiled with a Linux compatibility library (Cygwin). But they don't have to be. This provides a less "Linux-like" experience but may be a good compromise if all you want are some Linux command line tools and don't need to install full-blown Linux executables.
Definition of PATH for both "environments" is different. Check that node's dir shows up on Git bash's and not in WSL Bash. Run this on both environments:
echo $PATH
I am tyring to understand linux file system layout. Why does the command work inside virtual box but not on linux shell on windows?
I tried to use the command sudo fdisk -l dev/sda on both my virtual box(Ubuntu) and Ubuntu on windows(from microsoft store). It didn't work on any of them but when I changed the command to sudo fdisk -l, it worked inside virtual box but not on linux bash shell on windows.
Inside linux shell on windows:
:~$ sudo fdisk -l /dev/sda
.
fdisk: cannot open /dev/sda: No such file or directory
:~$ sudo fdisk -l
fdisk: cannot open /proc/partitions: No such file or directory
:~$ man fdisk
:~$ whereis fdisk
fdisk: /sbin/fdisk /usr/share/man/man8/fdisk.8.gz
The fundamental of Windows Subsystem for Linux (WSL) - Ubuntu is a POSIX emulator which is like Cygwin kind of environment helps to port some Linux based commands/applications running on windows platform as windows process.
It contains an abstraction layer of a virtual filesystem (vfs) which has read-only app image & RAM based writable tmpfs and neither it doesn't have access control to read the raw devices on host system nor it emulates the raw devices for the subsystem.
from man(fdisk) :
Description
This command is used to create and modify the partition table, and to install the master boot (IA only) record that
is put in the first sector of the fixed disk. This table is used by
the first-stage bootstrap (or firmware) to identify parts of the disk
reserved for different operating systems, and to identify the
partition containing the second-stage bootstrap (the active Solaris
partition). The rdevice argument must be used to specify the raw
device associated with the fixed disk, for example,
/dev/rdsk/c0t0d0p0.
So WSL-Ubuntu can't execute the fdisk command successfully since it doesn't have its own kernel to manage host resources.
On the other hand, Oracle's VirtualBox is a virtualized system which imitates a fully functional OS running on bare metal. It simulates its own system-space & user-space with the help of virtualization hypervisor and manages the virtual resources via the Guest OS kernel. This is why fdisk command execution was successful on VirtualBox
Reference :
https://www.microsoft.com/en-us/research/wp-content/uploads/2013/01/posix-emulation-submitted.pdf
Credits: https://www.quora.com/How-is-Windows-Subsystem-for-Linux-different-from-running-Linux-on-Windows-in-a-VM
I'm interested in web development on the Node.js platform. My host OS is Windows 7. What would be the preferd way to set up a development environment. Run it directly on the host or in a linux based virtual machine? What are the pros and cons between these two methods?
If I go with a VM, can I still run the text editor and web browser in Windows (for performance reasons)?
Eh from experience, use Linux Docker.
edit Use Docker. bake in your dependencies, mount your project at run time, pin to a particular version of LTS node only. I'd take a 2gb docker image over un-runnable project leading to days lost being forced to upgrade to new packages. - 2018/04/10
But from someone whose spent the last 8 years developing in a linux based environment, and having spent the last 6 months developing software using nodejs in a windows dot net environment, here are my discoveries, shocking or otherwise...
Problems on windows:
can't effectively utilise docker Latest version of the docker toolkit solves this as far as I'm concerned. ymmv.
most node modules require node_gyp, which on the surface doesn't seem problematic (since gyp is supposed to be cross platform compiler), except when you delve into what it takes to get this working on windows: nothing short of installing visual studio will work. This sucks for me due to several reasons:
I'm normally on linux, so I never want to have to use visual studio.
It's entirely the most ridiculous idea that compiling something on windows requires at minimum a 3GB installation of an IDE... not libs but an entirely monolithic piece of GUI software I'll never ever launch.
the windows equivalent of debians build-essentials is actually a disparate sprawling ill named collection of gui only installers scattered across the internet all requiring a specific installation sequence. This, compared to sudo apt-get install build-essentials is overly time consuming and fraught with hidden gotchas.
developing on windows will allow you the bad habit of mixed case path names, unless your team either has a strict policy that is followed/enforced this will be a slippery slope to problems later on.
while windows supports more than 256 characters in paths, important tooling through out does not. enter stage left: rimraf and robocopy... ugh.
the windows terminal sucks... so does the default shell: cmd.exe...
Powershell is far too verbose in it's syntax and not to my taste... Installing Cmder aleviates this somewhat, however the only way for Cmder to interface with cmd.exe is to basically copy keystrokes to a hidden windows terminal running cmd.exe. (lolwut). Cmder works a lot better with shells that a more modular (zsh, bash, etc).. update: I now use powershell with pshazz and scoop, which is actually pleasant to use.
Having still improved the shell and terminal situation, nodejs for
windows will still assume your environment variables are %OF% %THE%
%WINDOWS% %VARIETY%... not the $UNIX $STYLE. So you'll basically be
using bower and npm mostly from cmd.exe... more ugh. I dont' seem to be having this issue anymore since I've incorporated a mix of cross-env and commander or yargs.
You'll also need to install python for windows, not a problem because choco exists and has you back there. update: have a look at boxstarter, will help automate your new machine setup with recipes (or you could actually graduate to using ansible or salt).
experienced python, ruby developers will tell you that old projects will need the version of their engine silo'd for when you need to revisit them (upgrading to newer versions is mostly not expedient or practical, read: rabbit holes), so you'll want something like rvm and virtualenv...
nvm (which only works on unix systems linux and macosx) because it's
a collection of bash scripts. I recommend using ZSH as your shell along with Zgen and Tarrasch/zsh-autoenv plugin.
nodeenv, which is more likely... a python program that integrates with virtualenv. Some people like this. I have no problem with it, but our team uses nvm.
however, you're better off with nvm-windows because "reasons". scratch that, use nodist on windows... bar far the better choice, you won't need to worry about some kind of autoenv since nodist by design handles this.
Installing on Windows:
install chocolatey
choco install cmder nodejs python2 choco install python2
install http://scoop.sh, then use it to install pshazz.
remove any versions of node manually installed globally.
install nvm-windows install nodist.
install visual-studio 2012 express, then never launch it if you treasure your cpu cycles. this may be overkill as microsoft have released an equivalent to build-essentials.
install windows 7/10 64bit sdk
Problems on Linux:
tldr; use nvm. for more reasons other than the below.
you'll have to set the global npm node_modules path to a user owned directory (I've started using ~/.local/share/npm). Pleasantly, this is something I found the windows installation of nodejs got right (probably not intentionally). A non issue when using nvm.
Ubuntu already has a binary called node, so #!/usr/bin/env node will by default not run nodejs. luckily debian systems have a neat management tool for controlling what the env binary emits: update-alternatives. ignore suggestions to use symlinks here, which will only cause problems later on in subtle ways. also a non issue when using nvm.
Installing on Linux :
$ sudo apt-get install git-core git-flow build-essentials python-dev python- pip
$ curl https://raw.githubusercontent.com/creationix/nvm/v0.20.0/install.sh | bash
$ npm config set prefix ~/.local/share/npm
$ nvm install stable
$ nvm alias default stable
references:
https://groups.google.com/forum/?fromgroups#!msg/msysgit/9YIR6jlNB0Q/zHhPN3tejFkJ
https://github.com/creationix/nvm
http://bliker.github.io/cmder/
https://github.com/coreybutler/nvm-windows
https://github.com/Tarrasch/zsh-autoenv
https://github.com/lukesampson/pshazz
http://scoop.sh
https://github.com/marcelklehr/nodist
We have a system via which we just use a config file, which handles all our problems like path differences ("c:\blarg" vs "~user/blarg") and, as a bonus, lets us control differences between debug and production environments.
Node.js is cross platform, so we totally have developers working on all sorts of computers, and it's no problem at all.
This is an example config file I use on a file storage project:
/**
* All of these are mandatory except for log_level (which defaults to "info", 1)
* and log_echo_to_console (which defaults to false)
*/
exports.config = {
log_level: 0,
log_file: "/path/to/send.log",
request_log_file: "/path/to/send_requests.log",
log_echo_to_console: true,
port_number: 8088,
no_notification_emails: true,
image_url_base: "http://s3.amazonaws.com/", // MAKE SURE THIS ENDS IN "/"
tmp_file_folder:"/tmp/",
s3_info: {
key: 'xxxxxx',
secret: 'yyyyy',
file_bucket: 'sendtransfer/',
},
backend_info: {
db_info: {
server: "localhost",
user: "db_user",
password: "secret",
database: "SendRemote",
pooled_connections: 125,
idle_timeout_millis: 30000
},
memcache_info: {
host: "127.0.0.1",
port: "31111",
pooled_connections: 200,
timeout: 20000
}
},
debug_server: true
};
For Windows machines, just change the paths. It's all good!
Then in code, you can just type:
var local = require('local.config.js');
fs.writeFile(local.config.log_file);
// etc
Embrace multiculturalism!!!
I am also on Windows 7 and use Virtualbox with a Linux ( debian ) guest, i would recommand it because I for myself am faster doing some stuff in the commandline then clicking arround in Windows.
Another nice feature is that if you put your VM on an USB stick you can take it with you and use it everywhere where a Virtualbox Host is installed, so you can take your whole development environment with you.
It's no problem at all to use your favourite text editor or browser in Windows, just install samba and mount your home directory into Windows.
Same goes for your browser since the VM is just another machine in your LAN, instead of pointing your browser to localhost point it to the VMs Ip and you are fine.
Obvious con here is if you don't have any experience with Linux yet you should probably stick to windows because it will take you some time to get into it.
just my two cents maybe even less:
I'll suggest you a third option: to double install windows/ubuntu setup (preferably ubuntu dist which is most gui friendly) and research this option as well this way you would be more familiar with the linux/unix and even iOS which will even make you understand windows better and a better programmer. Sometimes the virtual box is too slow, while linux is very efficient with resources.
If you have the ability to install a virtual machine,you can also give a go to installing a linux distribution and get yourself familiar with this language/system of OS which a lot of the web is structured upon
I really enjoy coding node.js on windows using git bash:
http://blog.nodester.com/post/19902515151/tips-for-windows-users
It's seems faster then and easier then running VirtualBox. Given that I still use Virtual Box for testing before going to production.