Foreign Linux: Run Linux binaries on Windows without drivers or modification(github.com)
github.com
Foreign Linux: Run Linux binaries on Windows without drivers or modification
https://github.com/wishstudio/flinux
148 comments
My biggest gripe with Cygwin (aside performance on some syscalls) has been package management, which used to require setup.exe to add or upgrade packages. That was nicely mitigated when I found out about apt-cyg[1]. It's a apt-getish frontend for setup.exe command line. Not as nice as real apt-get of course, but "apt-cyg install something" takes care of the most important use case.
1: https://github.com/transcode-open/apt-cyg
EDIT: changed to github url
1: https://github.com/transcode-open/apt-cyg
EDIT: changed to github url
It would also be really nice if Cygwin did a quick ping on all of the package hosts and then ordered them in order of least latency relative to you. Oftentimes I have to re-start the install process because I accidentally chose a host that's slow enough to delay the install for hours.
I wish it would sort by network throughput instead of latency.
Babun provides an nice layer over cygwin (preinstalled oh-my-z and other goodies) along with an excellent package manager as well. https://github.com/babun/babun
Which is based on apt-cyg AFAIK. And I missed the the ``apt-get upgrade`` functionality in both pact/apt-cyg.
Indeed. It's kind of weird there's no package manager beyond setup.exe in Cygwin. There's even a port of rpm in the package collection. I wonder if Cygwin misses some bigger piece of functionality that is a requirement for rpm. Or maybe it's just good enough for most of use cases.
Problem with apt-cyg is the occasional need to "rebaseall" to keep the cygwin dll's happy. a proper package manager would be nice, though it is a good solution all things considered.
Couple apt-cyg with a batch script to install updates unattended - this made cygwin much nicer:
cd C:\distr\cygwin setup-x86_64.exe --no-desktop --no-shortcuts --no-startmenu --quiet-mode
cd C:\distr\cygwin setup-x86_64.exe --no-desktop --no-shortcuts --no-startmenu --quiet-mode
For me, Cygwin makes Windows bearable. It's still Windows, but, at least, it has a proper shell, interpreters, compilers, compressors (no need for WinZip or WinRAR - think about it!) and so on. For the same reason you need MacPorts or Brew on a Mac, you need Cygwin on Windows.
Unless you are happy to spend your day in Visual Studio, in which case Cygwin will not be that useful.
Unless you are happy to spend your day in Visual Studio, in which case Cygwin will not be that useful.
Windows has had a proper shell for a while now, in the form of PowerShell. It's quite different from the standard Unix shell, and I'm nowhere near as productive in it as I am in Bash, but that's more a function of lack of familiarity than any weaknesses of the shell. In fact, I'd say that it's actually much nicer than unix-y shells for a wide variety of tasks.
All I really find missing these days is good line-editing, and a half-decent terminal emulator in which to run the shell.
All I really find missing these days is good line-editing, and a half-decent terminal emulator in which to run the shell.
> All I really find missing these days is good line-editing
Probably familiar enough for bash people:
https://github.com/lzybkr/PSReadLine
> and a half-decent terminal emulator in which to run the shell.
Not a terminal emulator (although I think it can do Terminal escape sequences if needed):
https://github.com/Maximus5/ConEmu
Probably familiar enough for bash people:
https://github.com/lzybkr/PSReadLine
> and a half-decent terminal emulator in which to run the shell.
Not a terminal emulator (although I think it can do Terminal escape sequences if needed):
https://github.com/Maximus5/ConEmu
It's still not a terminal emulator, but you can use Clink [1] to get readline in cmd. Works great with ConEmu or as part of cmder, as others have mentioned.
[1]: http://mridgers.github.io/clink/
[1]: http://mridgers.github.io/clink/
Very high ROI. Removes a lot of stress you got just typing cmd.exe.
I knew about ConEmu (though I'm not 100% happy with it either). I'll take a look at PSReadLine, thanks.
However great powershell is, the fact that bash is so universal everywhere else makes it too hard for me to use. With Cygwin I can often move seamlessly between Linux, OSX and Windows without changing anything I do, including all the utility scripts I write etc.
> and a half-decent terminal emulator in which to run the shell.
On Cygwin, try MinTTY. The default cmd.exe console is horrendous. This is derived from PuTTY and much, much nicer.
On Cygwin, try MinTTY. The default cmd.exe console is horrendous. This is derived from PuTTY and much, much nicer.
You can even use MinTTY with cmd.exe (and probably powershell) for dramatically improved user experience.
And, you can also find MinTTY standalone separate from the burden of cygwin. I got it from the msys project.
And, you can also find MinTTY standalone separate from the burden of cygwin. I got it from the msys project.
> It's quite different from the standard Unix shell
And that's the issue. Most people don't want to relearn everything, and I don't see why MS had to reinvent the wheel.
And that's the issue. Most people don't want to relearn everything, and I don't see why MS had to reinvent the wheel.
Do you know how to echo text in ASCII or UTF-8?
> "text" or
> echo "text"
For me both come out with weird character encoding
> WinZip or WinRAR
Everyone uses 7Zip now which has a very good command line version and is OSS/free (mostly LGPL licensed, but some of their source code is licenced otherwise because it is from third parties).
Plus Powershell can zip/unzip using the shell.application.Namespace API if you wish. I prefer 7zip myself, but Windows handles basic zip files fine.
Everyone uses 7Zip now which has a very good command line version and is OSS/free (mostly LGPL licensed, but some of their source code is licenced otherwise because it is from third parties).
Plus Powershell can zip/unzip using the shell.application.Namespace API if you wish. I prefer 7zip myself, but Windows handles basic zip files fine.
Explorer does too when not at command-line.
>(no need for WinZip or WinRAR - think about it!)
I'd be surprised if compressor utilities running through Cygwin's emulation layer could achieve the same speed as a native tool. 7-zip is an open source tool that will handle all your compression / decompression needs on Windows (including rar, gz, many self-extracting exes, and a bunch of very exotic formats). You should really give it a try if you're compressing or decompressing large archives on Windows.
http://www.7-zip.org/
I'd be surprised if compressor utilities running through Cygwin's emulation layer could achieve the same speed as a native tool. 7-zip is an open source tool that will handle all your compression / decompression needs on Windows (including rar, gz, many self-extracting exes, and a bunch of very exotic formats). You should really give it a try if you're compressing or decompressing large archives on Windows.
http://www.7-zip.org/
Cygwin should only slow down syscalls. Syscalls should not be a significant fraction of the running time of compression software.
> I'd be surprised if compressor utilities running through Cygwin's emulation layer could achieve the same speed as a native tool.
Why do you think so? The emulation layer should only be relevant for the IO part of the compressors and IO is usually severely limited by the harddisk anyway.
Why do you think so? The emulation layer should only be relevant for the IO part of the compressors and IO is usually severely limited by the harddisk anyway.
cygwin is fine, but if you want to spend most of your time in bash or using software designed for Unix you probably shouldn't be using Windows in the first place.
Unless you need Windows just slightly more than you need Linux, or your hardware doesn't work properly under Linux, or you need software that Linux, even Wine, can't run. Or your processor isn't even capable of booting Linux, but it can run Windows (Intel Atom Bay Trail comes to mind).
--edit apparently Bay Trail does support Linux. The big hype when it was launched was that it would not, that's where my confusion came in
--edit apparently Bay Trail does support Linux. The big hype when it was launched was that it would not, that's where my confusion came in
I mean, no problem, but, ultimately, cygwin is walled off from certain parts of the system and you're just going to have to deal with the fact that WinNT has major differences from Linux for some tasks. I use cygwin sometimes too but it makes more sense "in addition to" than "instead of."
Linux runs on Bay Trail,
e.g. https://www.happyassassin.net/fedlet-a-fedora-remix-for-bay-...
the problem was the 32 bit UEFI. Also solved: http://unix.stackexchange.com/questions/155557/installing-li...
the problem was the 32 bit UEFI. Also solved: http://unix.stackexchange.com/questions/155557/installing-li...
actually I'm pretty sure Bay Trail do run Linux.
Unless your business requires software which only runs on Windows, and using cygwin allows you to do a lot of things better on Windows, and lets you do a lot of things cross platform that would be a waste of time to implement two ways.
I'd be more inclined to agree with you if you'd ended that statement with "... designed for Unix, perhaps you should consider whether you should be using Windows in the first place".
There are a lot of people out there that have to use Windows for a variety of reasons, but are glad to be able to do some shell-related things on it in a unix-like shell.
I'd be more inclined to agree with you if you'd ended that statement with "... designed for Unix, perhaps you should consider whether you should be using Windows in the first place".
There are a lot of people out there that have to use Windows for a variety of reasons, but are glad to be able to do some shell-related things on it in a unix-like shell.
I'm a bit split at this point.. in general, I have an ubuntu server VM running (with docker), with my home directory mounted via samba as a drive in windows, and have a couple conemu tabs open ssh'd into the VM... I can continue to edit in windows, but run in Linux.
At least for my stuff that will run in Linux (node/iojs and golang) targeting docker containers, it works well.
At least for my stuff that will run in Linux (node/iojs and golang) targeting docker containers, it works well.
A lot of people are stuck at jobs where they need Windows for some reason or another (maybe simply because their boss says so).
In those cases, Cygwin makes their life bearable.
I also want to out in a good word for Cygwin. It's fantastic, I have absolutely no complaints about it. I have python and GCC, as well as a fully working shell. I can do Linux development in either of my favorite languages (Python and C++) without any kind of worry, and they work without modification on Linux.
Plus, having a working Bash with everything I want on Windows blows my mind.
Plus, having a working Bash with everything I want on Windows blows my mind.
Is it better than using virtualbox?
It applies a Linux-like polish to a Windows machine. You can manipulate the whole Windows filesystem from within a Linux-like environment. With a VM you get a full Linux environment that cannot simply get to your Windows environment - you get a clear separation between the two.
I like to say Cygwin "civilizes" Windows.
I like to say Cygwin "civilizes" Windows.
I agree. And when you add Chocolatey to the mix (just add it with an elevated cmd.exe as stated on chocolatey.org), you're about half-way to a GNU/Linux-ish Windows. (In elevated PowerShell, I actually used "choco install cygwin -y" after doing so!) I think in Windows 10 this is supposed to be even better with their OneGet framework that will be compatible with Choco. Things are looking better for those who have to use Windows but want the power of the GNU/Linux environment. It is thanks to which I no longer need VirtualBox anymore, granting the benefit of allowing me to run code a little more efficiently.
The only gripe I have is I would really like to use openssh-server on Windows the way I do on GNU/Linux. I have yet to find a comparable solution that is opensourced and free.
The only gripe I have is I would really like to use openssh-server on Windows the way I do on GNU/Linux. I have yet to find a comparable solution that is opensourced and free.
Chocolatey is a bit of a security nightmare just waiting to happen. I heard it has a veto system now but it would have been better to design it from the ground up to use a central repo where people could do pull requests. The lack of review and arbitrary ownership of packages makes it very iffy, particularly on work/production workstations or servers.
You're right about the security aspect, which is what Microsoft says OneGet will also attempt to resolve (in effect, replacing chocolatey's repo with theirs, I'd assume).
I believe MS wants you to use remote Powershell instead of SSH.
I dig the ability to cross into remote file systems transparently (much like PowerShell). Running "df -h //devwinserver1/c$" is cool, as is the ability to clean up cruft when a Nagios disk alert goes off, all from the comfort of my bash shell.
Plus, with Xwin running, I can utilize cluster SSH to make managing Unix servers a bit less painful from my Windows machine (corporate standard image I have no control over).
Plus, with Xwin running, I can utilize cluster SSH to make managing Unix servers a bit less painful from my Windows machine (corporate standard image I have no control over).
I like to say that Cygwin gives me the best of both worlds because Linux desktop environments simply lack the polish that the Windows desktop has.
Sometimes a linux VM won't cut it, like on corporate networks heavily invested in Windows infrastructure (activedirectory domains and many layers of authentication that are either difficult or impossible to interop with linux).
It took many years before I realized and tried it, but Cygwin also very easily lets you run an OpenSSH server on Windows, which I find incredibly useful.
And it's also the only reasonable and free option for this. (Correct me if I'm wrong but I've tried)
I've used Cygwin a lot in the past; it's great provided you don't have to stray outside the Cygwin world. If you need to interact with standard Windows executables it gets very hairy. In order to maintain Unix-ish semantics, it needs to do some rather odd things --- IIRC stderr is passed via a Windows named pipe rather than via the Windows file descriptor 2?
And heaven help you if you need to run a Cygwin binary on a system with a different version of Cygwin installed on it...
We found ourselves switching to MSYS whereever possible simply because it was less clever, and therefore more predictable.
(Also the Cygwin package manager makes me sad.)
And heaven help you if you need to run a Cygwin binary on a system with a different version of Cygwin installed on it...
We found ourselves switching to MSYS whereever possible simply because it was less clever, and therefore more predictable.
(Also the Cygwin package manager makes me sad.)
For me I've had too many problems with cygwin and $DAYJOB installs BLODA, so I'm really interested to see what comes of this, also since it uses arch and pacman, which are my distro of choice, it sounds pretty perfect to me! (no more having to recompile everything from source with cygwin or `rebaseall` and suchlike)
BLODA: Big List Of Dodgy Apps
Hmm, Have you looked at http://mobaxterm.mobatek.net/ before. I found this less of a hassle to install and work with, than cygwin.
Hmm... seems interesting, I still like the idea of this foreign-linux, it seems like the idea has a lot of potential. Thanks.
I don't think it is fair to compare it with Arch packages in numbers. How many of these are really usable? Cygwin is a limited environment per se.
In this sense, it is better to compare msys2 with Arch packages, since msys2 uses pacman.
In this sense, it is better to compare msys2 with Arch packages, since msys2 uses pacman.
This has been tried before as the author notes. E.g.
http://lbw.sourceforge.net/
Previous experiments have stumbled on Linux usage of %gs and other segmentation issues.
The present project is possibly trying to overcome those obstacles with dynamic recompilation. It's in very early stages though.
http://lbw.sourceforge.net/
Previous experiments have stumbled on Linux usage of %gs and other segmentation issues.
The present project is possibly trying to overcome those obstacles with dynamic recompilation. It's in very early stages though.
Hey, I resemble that project!
Yeah, it ground to a halt due to fundamental differences in the way Linux and Windows binaries work. I'm actually now kind of scared at how much working hackery LBW ended up containing: it'd dynamically patch the binary after trapping out at instructions manipulating things that Windows wouldn't allow access to.
(The LBW instruction patching code is here. It's entertainingly bonkers. http://sourceforge.net/p/lbw/code/ci/master/tree/src/ehandle...)
Not all the horror was Windows, mind: Linux's interface to executables is barely documented and extremely fragile, involving passing a key-value table full of magic parameters on the stack after the argument and environment tables. And, of course, I'd have to replicate this otherwise glibc would crash out. (At least, I thought I did --- I cannot now find any of the actual code. Maybe I got rid of it?)
I eventually gave up because it was obviously not a tenable approach. Plus, it'd completely fail on 64-bit platforms. Dynamic recompilation is obviously a way more preferable approach. If I ever have to use Windows again, god forbid, I'm definitely checking this out.
Yeah, it ground to a halt due to fundamental differences in the way Linux and Windows binaries work. I'm actually now kind of scared at how much working hackery LBW ended up containing: it'd dynamically patch the binary after trapping out at instructions manipulating things that Windows wouldn't allow access to.
(The LBW instruction patching code is here. It's entertainingly bonkers. http://sourceforge.net/p/lbw/code/ci/master/tree/src/ehandle...)
Not all the horror was Windows, mind: Linux's interface to executables is barely documented and extremely fragile, involving passing a key-value table full of magic parameters on the stack after the argument and environment tables. And, of course, I'd have to replicate this otherwise glibc would crash out. (At least, I thought I did --- I cannot now find any of the actual code. Maybe I got rid of it?)
I eventually gave up because it was obviously not a tenable approach. Plus, it'd completely fail on 64-bit platforms. Dynamic recompilation is obviously a way more preferable approach. If I ever have to use Windows again, god forbid, I'm definitely checking this out.
There's also LINE and coLinux.
This looks like an interesting project to keep an eye out for. On the topic of cygwin, I would also like to recommend mobaXterm, that I use instead of cygwin nowadays... It is an interesting choice in the alternatives we have. So, those of you that use cygwin, take a look at it here: http://mobaxterm.mobatek.net/
If you are thinking about trying cygwin, I would recommend this instead, as the installation is relatively easier when compared to cygwin. (I have no affiliation to mobaxterm)
Another new indispensible tool for me is cmder, which leverages ConEmu, clink and mysysgit to provide a wonderful UX in the commandline for me - just brilliant. Here: http://bliker.github.io/cmder/
Memo to self: Spend the next 4 months learning powershell during lunch breaks!
If you are thinking about trying cygwin, I would recommend this instead, as the installation is relatively easier when compared to cygwin. (I have no affiliation to mobaxterm)
Another new indispensible tool for me is cmder, which leverages ConEmu, clink and mysysgit to provide a wonderful UX in the commandline for me - just brilliant. Here: http://bliker.github.io/cmder/
Memo to self: Spend the next 4 months learning powershell during lunch breaks!
The big problem with MobaTerm is that it includes really old versions of the standard unix utilities, and it's difficult to integrate with newer & missing utilities. This isn't a problem that's limited to MobaXTerm, but the way MobaXTerm does things makes it harder to fix.
Let's say you want to set up a standard dev setup. So you install MobaXTerm, vagrant, emacs, msysgit, and rsync. Each of these require SSH for full operation, so in the interest of making things easy, the installers bundle SSH. You now have up to 5 copies of SSH installed, all storing their private keys, cert stores and configuration in different places. What a mess. And some things aren't compatible with each other. IIRC, vagrant is built with cygwin, so you have to make sure you use a cygwin rsync with it, the msys rsync won't work.
To keep everything sane, start with the standard cygwin or msys installer, and install everything using that.
Does conemu include mingw-get? If so, that sounds like it might be a good solution. If not, I recommend avoiding it.
Or just reformat and install Linux. That's what I ended up doing. Putting up with poor HiDPI support in Linux was much more tolerable than the horrors of trying to use Unix utilities in Windows. And HiDPI support is improving quickly in Linux land....
Let's say you want to set up a standard dev setup. So you install MobaXTerm, vagrant, emacs, msysgit, and rsync. Each of these require SSH for full operation, so in the interest of making things easy, the installers bundle SSH. You now have up to 5 copies of SSH installed, all storing their private keys, cert stores and configuration in different places. What a mess. And some things aren't compatible with each other. IIRC, vagrant is built with cygwin, so you have to make sure you use a cygwin rsync with it, the msys rsync won't work.
To keep everything sane, start with the standard cygwin or msys installer, and install everything using that.
Does conemu include mingw-get? If so, that sounds like it might be a good solution. If not, I recommend avoiding it.
Or just reformat and install Linux. That's what I ended up doing. Putting up with poor HiDPI support in Linux was much more tolerable than the horrors of trying to use Unix utilities in Windows. And HiDPI support is improving quickly in Linux land....
I agree with your point on the very clumsy SSH tack-on take up with this approach.
About the older utilities, again, I completely agree. But, the way to create the mx3 bundles is easy. Actually, on the website/forums, several users there have been a few 3rd party utilities of the same. The format is transparent for anyone to create their own set of utilities on top of what mobs provides.
About the older utilities, again, I completely agree. But, the way to create the mx3 bundles is easy. Actually, on the website/forums, several users there have been a few 3rd party utilities of the same. The format is transparent for anyone to create their own set of utilities on top of what mobs provides.
MobaXterm is sweet... If nothing else it's a game changer for putty users.
Yeah the ecosystem is kinda small for whatever reason. I tried setting up cyg-apt for it, and it almost worked. I guess if they made the regular cygwin package manager work rather than dropping a bunch of binaries into the same directory as the mobaxterm binary that would be a good start, but then maybe that would conflict with their business model.
Yeah the ecosystem is kinda small for whatever reason. I tried setting up cyg-apt for it, and it almost worked. I guess if they made the regular cygwin package manager work rather than dropping a bunch of binaries into the same directory as the mobaxterm binary that would be a good start, but then maybe that would conflict with their business model.
Unfortunate that MobaXterm is not free (as in freedom) software, but looks VERY nice from the website. I'm very tempted, although I don't do much remote administration anymore.
So it's cool, and a lot of people might see it as a bad thing that if this took off could potentially bring Linux users back to Windows. I personally think it could do the reverse though and encourage people to try Linux. If they enjoy using some small selection of tools that work on Windows (presumably all CLI tools) then they might be convinced to give a full distro a go. Interesting concept though and I really hope it works out.
I think it would mainly be used by Linux users forced to use Windows for some reason (at work, for example).
I totally agree with you. Some of us who really like Linux are forced to use Windows at work. This project is really going to help a lot of people :)
But if you can run this, you can run VirtualBox, which is a much safer alternative (and simpler, if a live ISO meets your needs).
Linux already does plenty to bring Linux users back to Windows. What’s this going to hurt?
If this can bring me a working * nix shell under Windows, I'd be extremely happy. Windows is great for everything except I have never learned PS as well as I know the * nix shells -- with this, I could enjoy the hardware and proper multi-monitor support, speed and stability (seriously) of Windows and use the * nix command line.
To be honest, and I say this with a massive cringe, after 20 years of Unix I'm more productive with PS in a couple of months! It's quite refreshingly easy to use and I genuinely had no idea how much time I was wasting on parsing streams.
Now I feel horrible for revealing my dirty secret :(
Now I feel horrible for revealing my dirty secret :(
What do you use for grep?
I tried using Powershell and did a few things with it, but while it is a great shell, the lack of good tools like grep prevented me from being really productive.
I tried using Powershell and did a few things with it, but while it is a great shell, the lack of good tools like grep prevented me from being really productive.
`select-string` or it's alias `sst`. I find myself filtering collections of objects far more frequently then grepping lines when using powershell.
I've ended up with
Select-String "pattern" -Path file.txt | ForEach-Object { Write-Output $_.Line } | Out-File t.txt
Slightly Heath Robinson, but by default PS will truncate lines to terminal width, even when writing to a file, which is a disaster for any kind of subsequent machine processing.
Select-String "pattern" -Path file.txt | ForEach-Object { Write-Output $_.Line } | Out-File t.txt
Slightly Heath Robinson, but by default PS will truncate lines to terminal width, even when writing to a file, which is a disaster for any kind of subsequent machine processing.
For the uninitiated this looks completely barbaric, but makes a whole lot of sense when you consider that PS is built around an object-based pipeline. 'Select-String' in PS doesn't actually return a string, but a 'MatchInfo' object, which contains more properties -- 'linenumber', 'context', etc, as well as the 'line' property which contains the actual matched lines as strings. The default output from any part of the pipeline is a human-readable/terminal-display-compatible representation of the object's commonly used properties, thus the truncation.
As an aside, you can replace the foreach with select-object for an efficiency gain:
As an aside, you can replace the foreach with select-object for an efficiency gain:
sls "Pattern" file.txt | select -exp line | out-file t.txtYou also don't technically need to go through Select-String if all you care about is the line itself:
(gc file.txt) -match "Pattern" | Out-File t.txt
Today, I learned "Heath Robinson" is British English for "Rube Goldberg"
http://en.wikipedia.org/wiki/W._Heath_Robinson
http://en.wikipedia.org/wiki/W._Heath_Robinson
You could also use either of these:
(Select-String "pattern" -Path file.txt).Line > t.txt
Select-String "Pattern" -Path file.txt | Select-Object -ExpandProperty Line > t.txt
sls pattern -path file.txt | select -exp line > t.txtDefault Windows shell also has `findstr`, which works very similarly to grep. It's also quite fast.
I use `where` for finding stuff, but that's based on structure rather than scraping.
Buts its not just the shell, its ps, kill, convert, ffmpeg... do you feel like you can do most stuff you do on linux in PS?
Installing ffmpeg and convert on Windows (without cygwin even) is trivial.
It looks like PowerShell even has kill (as an alias to Stop-Process) and ps (as an alias to Get-Process).
I don't like PowerShell, but I certainly wouldn't be quick to suggest that it is missing features.
It looks like PowerShell even has kill (as an alias to Stop-Process) and ps (as an alias to Get-Process).
I don't like PowerShell, but I certainly wouldn't be quick to suggest that it is missing features.
Yeah, I think the object pipeline is very nice.
You're a .Net developer who wrote a C# framework back in 2004 and consistently posts about how great Windows is and how poor Linux is.
At a wild guess I'd say that's why you're "more productive with PS in a couple of months".
At a wild guess I'd say that's why you're "more productive with PS in a couple of months".
FWIW, my current setup is Win 8.1 Pro with Hyper-V configured to startup a Linux VM on boot. My dev environment consists of cmder with an alias "dev" that ssh into the Linux VM where I have my full set of dev tools available. It's almost completely seamless since vim is my editor and I can just run that over ssh.
Cygwin and MSYS2 are really underrated for this. I think they do exactly what you want. I often use Bash and find to manage files on Windows.
It's not quite the same...but Git Bash for Windows[1] is an awesome substitute for the Windows command prompt.
[1] http://git-scm.com/downloads
[1] http://git-scm.com/downloads
AFAIK, that's actually MSYS. But since I need git anyway, I'm using exactly that, together with MinGW-w64 and it works quite well.
you seriously need to learn PS.
I'm totally lovin' it.
Always nice to have more alternatives, but I find either http://bliker.github.io/cmder/ (a tricked out console with a nicely tweaked git bash environment) or http://babun.github.io/ (Cygwin but easier to install and with nicer defaults) better for daily use when forced to wallow in the Windows pool at work.
Firstly, this looks brilliant. If anyone can remove the extra layers of cygwin, mingw, xming etc. and provide a direct ability to execute linux programs from powershell/cmd , I call Black Magic. Voodoo I tell you; Windows cannot be this user friendly (I work with it every day).
Secondly, completely off topic, I noticed that Github picks up 0.4% of the code-base as Objective-C (https://github.com/wishstudio/flinux/search?l=objective-c) due to the files functionally consisting of a single line, `#pragma once`. Is this statement more common in Objective-C than C or C++ ? Just wondering if Github detects the language based partly on some statistical analysis of other existing code, or if it has "set rules".
Secondly, completely off topic, I noticed that Github picks up 0.4% of the code-base as Objective-C (https://github.com/wishstudio/flinux/search?l=objective-c) due to the files functionally consisting of a single line, `#pragma once`. Is this statement more common in Objective-C than C or C++ ? Just wondering if Github detects the language based partly on some statistical analysis of other existing code, or if it has "set rules".
Github's language detection is actually open-source — you can have a look at what it does here: https://github.com/github/linguist
Linguist uses a number of different 'strategies' to identify the language – in the case of C vs. Objective C, it uses a pretty simple heuristic (https://github.com/github/linguist/blob/master/lib/linguist/...) to disambiguate C/C++/ObjC where required (such as in header files, which can't be disambiguated by file extension.)
In this case, the content of the file can't be reliably disambiguated, so I imagine it'll probably fall back to the Bayesian classifier. Interesting that the classifier identifies it as Objective C though!
Linguist uses a number of different 'strategies' to identify the language – in the case of C vs. Objective C, it uses a pretty simple heuristic (https://github.com/github/linguist/blob/master/lib/linguist/...) to disambiguate C/C++/ObjC where required (such as in header files, which can't be disambiguated by file extension.)
In this case, the content of the file can't be reliably disambiguated, so I imagine it'll probably fall back to the Bayesian classifier. Interesting that the classifier identifies it as Objective C though!
I'm not a programmer so bear with me.
They have a cadre of samples in the project, searching on "#pragma once" shows no examples of Objective-C (that I can see) using that line but does show C/C++ examples with it. Is that the input to the classifier?
The heuristic you linked appears to default to identifying as C; that regex doesn't look like it has anything to make the else-if return the sample as Obj-C.
I'd have expected the fact that most other files on the project were C to be the dominant factor that - without any other positive result in the classifier - would weight the files as being C. Presumably this data isn't used in classifier though?
Interesting.
They have a cadre of samples in the project, searching on "#pragma once" shows no examples of Objective-C (that I can see) using that line but does show C/C++ examples with it. Is that the input to the classifier?
The heuristic you linked appears to default to identifying as C; that regex doesn't look like it has anything to make the else-if return the sample as Obj-C.
I'd have expected the fact that most other files on the project were C to be the dominant factor that - without any other positive result in the classifier - would weight the files as being C. Presumably this data isn't used in classifier though?
Interesting.
Thanks for the link! Time to do some reading.
This is quite funny, since you can't run unmodified linux binaries on other linuxes (that is a binary distribution on linux is generally not a thing and there will always be a distribution that does stuff just differently enough), so a recompilation on windows sounds like as good of a solution.
The system call interface in linux is actually pretty stable. You can often run old binaries (at least ELF binaries) and binaries from different distributions as long as you have the shared libraries to go with them (including glibc). You can use a chroot or mess around with LD_LIBRARY_PATH.
I remember from trying to use Linux on a desktop machine (and this was like a decade ago so maybe it's no longer relevant) that graphics drivers were often distributed only as binaries.
And I remember (from a decade ago as well) having to recompile my kernel to use those binary graphics drivers :)
This is brilliant! Much more light weight than a VM. I hope they can iron out the remaining kinks.
I used coLinux many moons ago, but it hasn't been updated in any significant way lately, and still doesn't work on 64-bit Windows.
I used coLinux many moons ago, but it hasn't been updated in any significant way lately, and still doesn't work on 64-bit Windows.
Very impressive. I'd appreciate if they could get WINE working under this though..... :-)
Actually there is an effort to make wine compile and run on Windows.
http://wiki.winehq.org/WineOnWindows
http://wiki.winehq.org/WineOnWindows
That's interesting, I wonder if it's mature enough to run on itself :-)
"Linux services for Windows NT"
This reminded me, with some nostalgia, of a long time ago using Cooperative Linux on my work Windows machine with sole intent of being able to use Amarok as my media player.
(Version 1.4, before Amarok turned to crap. I use Clementine now, which has a native Windows port.)
(Version 1.4, before Amarok turned to crap. I use Clementine now, which has a native Windows port.)
I admit that I am a bit lost as to the value of this endeavour, or Cygwin for that matter, in an era where just about all commodity hardware can sustain virtualisation.
I used to have the problem of my dayjob requiring me to run Windows and use Outlook/Exchange, and Cygwin was a useful means of coping with that. But that was back in 2006. Now, it seems to me one should just fire up a Linux VM in VirtualBox, full-screen it, and pretend the encapsulating Windows doesn't exist.
I used to have the problem of my dayjob requiring me to run Windows and use Outlook/Exchange, and Cygwin was a useful means of coping with that. But that was back in 2006. Now, it seems to me one should just fire up a Linux VM in VirtualBox, full-screen it, and pretend the encapsulating Windows doesn't exist.
or Cygwin for that matter, in an era where just about all commodity hardware can sustain virtualisation.
I use cygwin primarily as an ssh client for my local linux VMs. My IDE is vim/tmux/zsh, and I've found ssh via cygwin provides an experience that closely resembles gnome-terminal in appearance and behavior (gnome-terminal being the best terminal emulator around IMHO)
I use cygwin primarily as an ssh client for my local linux VMs. My IDE is vim/tmux/zsh, and I've found ssh via cygwin provides an experience that closely resembles gnome-terminal in appearance and behavior (gnome-terminal being the best terminal emulator around IMHO)
seems overkill, wouldn't just putty do in your case?
As I said, I prefer cygwin's look and feel to the alternatives. Also, cygwin supports transparent windows out of the box. I don't think it's overkill at all, the only package you need is ssh, everything else lives in the VM.
Wondering how well fork() works?
I was wondering the same thing. The features page claims "copy on write fork implementation" but that is not universally true. A cursory look at the code suggests that every allocation is a Win32 file mapping object (aka NT section) underneath, which the fork worker (mm_fork) remaps into the forked process. This means the memory is shared between two processes, and not in a CoW fashion. A write to the memory region from the forked process will be visible in the parent. These are not correct semantics for fork.
I am hoping I misread the code and someone can prove me wrong here, because it looks like a cool project with a lot of potential.
I am hoping I misread the code and someone can prove me wrong here, because it looks like a cool project with a lot of potential.
From little I've read on cygwin mailing list (btw, cool folks over there) - it seems the problem is not very easy. If I'm not mistaken the Windows Kernel actually does support fork()-ing, but the win32k system somehow "forbids" it (lots of grains of salt). After all for a long time there was a commercial UNIX compatible offering on Windows that probably used fork() all over and must've worked (also it supported case-sensitive names for the filesystem)
BTW, the coolest usage of fork(), and granted a pain in the ass to port possibly was the one in REDIS where antirez used it to fork() at certain time the current process, then write back the state of memory knowing that it'll get a "snapshot" of it, and if writes to disk succeed, this "snapshot" would correctly and fully be written to the disk.
I know there are plenty of other uses (for example this way "lua" can do threads with just a bit of a communication library on top... e.g. any language without explicit thread handling can actually use them).
Wondering what made win32k folks disable it. Possibly there are lots of gotchas...
BTW, the coolest usage of fork(), and granted a pain in the ass to port possibly was the one in REDIS where antirez used it to fork() at certain time the current process, then write back the state of memory knowing that it'll get a "snapshot" of it, and if writes to disk succeed, this "snapshot" would correctly and fully be written to the disk.
I know there are plenty of other uses (for example this way "lua" can do threads with just a bit of a communication library on top... e.g. any language without explicit thread handling can actually use them).
Wondering what made win32k folks disable it. Possibly there are lots of gotchas...
Using fork to get a "snapshot" of memory seems... like a roundabout way of doing things. The underlying memory mapping mechanism should expose a simple way of just doing it directly. (I still don't understand the point of fork, especially when most of the time exec is just gonna overwrite things anyways. And the impact fork has is to massively increase potentially used memory, leading to the dumb memory overcommit semantics and hack fixes like OOM killer.)
Yup. indeed, but it seems so elegant, in the same way (elegant) as one can implement undo using closures - at the expense of unaccounted resources (cpu, memory, who knows what else).
From redis's page: http://redis.io/topics/persistence
"RDB needs to fork() often in order to persist on disk using a child process. Fork() can be time consuming if the dataset is big, and may result in Redis to stop serving clients for some millisecond or even for one second if the dataset is very big and the CPU performance not great. AOF also needs to fork() but you can tune how often you want to rewrite your logs without any trade-off on durability"
From redis's page: http://redis.io/topics/persistence
"RDB needs to fork() often in order to persist on disk using a child process. Fork() can be time consuming if the dataset is big, and may result in Redis to stop serving clients for some millisecond or even for one second if the dataset is very big and the CPU performance not great. AOF also needs to fork() but you can tune how often you want to rewrite your logs without any trade-off on durability"
As cool as this is, a remaining problem I'd have for using Windows is that I've found git to be slow there. For example, the responsiveness of 'git status'. I'd guess this is something to do with NTFS being optimised for things different than unix-tradition filesystems. If so, this tool wouldn't improve that. Does anyone know more about this area?
Git is built for Linux and relies on some features of Linux filesystems for speed. As long as underlying filesystem is NTFS, there's no way to speed up Git.
Although, the "Support NTFS native hardlinks and emulated symbolic links" could be relevant if it does some magic there.
Although, the "Support NTFS native hardlinks and emulated symbolic links" could be relevant if it does some magic there.
> Git [...] relies on some features of Linux filesystems for speed.
Modern NTFS versions support all the things that git needs, so it has less to do with having magical features in Linux filesystems per se and more with the fact that they aren't properly mapped onto respective NTFS features in the abstraction layer (MSYS or similar).
Modern NTFS versions support all the things that git needs, so it has less to do with having magical features in Linux filesystems per se and more with the fact that they aren't properly mapped onto respective NTFS features in the abstraction layer (MSYS or similar).
I wondered about the emulated symlinks here, though. NTFS supports symlinks just fine or maybe I'm not aware of a crucial difference in how they work in NTFS and Linux filesystems.
I really want Linux emulation for OSX, which should be much easier. FreeBSD had very usable Linux emulation on a similar kernel.
Cmd.exe is an abomination though - and Cygwin defaults to using it for terminal use. I see that this project also does that.
> Cmd.exe is an abomination though
Agreed, but I don't think Cygwin defaults to it any more. It uses mintty now, which understands Cygwin ptys and has a native Windows interface.
I guess you could also use an X11 terminal emulator in this project.
Agreed, but I don't think Cygwin defaults to it any more. It uses mintty now, which understands Cygwin ptys and has a native Windows interface.
I guess you could also use an X11 terminal emulator in this project.
Correct. Cygwin has used mintty as a default since 2011[1].
[1]: http://cygwin.com/ml/cygwin-announce/2011-11/msg00040.html
[1]: http://cygwin.com/ml/cygwin-announce/2011-11/msg00040.html
> Cmd.exe is an abomination though - and Cygwin defaults to using it for terminal use. I see that this project also does that.
Use http://mridgers.github.io/clink/
It is not an alternative terminal, but injects itself into every cmd process to allow completion, better key handling etc. I was skeptical at first, but it's a really, really great tool.
Use http://mridgers.github.io/clink/
It is not an alternative terminal, but injects itself into every cmd process to allow completion, better key handling etc. I was skeptical at first, but it's a really, really great tool.
Cmd.exe isn't a terminal emulator, it's a shell. Conhost.exe (and before Windows 7, csrss.exe) is the process behind the terminal window.
Can't you use cygwin with PowerShell?
cmd.exe is _not_ the console subsystem. It's just another program running in it. If you run bash, there's no cmd to be found anywhere. Just as your shell is not your terminal emulator the same holds true on Windows.
I am getting error when using go
[root@ForeignLinux ~]# gccgo hello.go -o test /tmp/cc06PbMI.o: file not recognized: File truncated collect2: error: ld returned 1 exit status
https://wiki.archlinux.org/index.php/Go
anyone experienced this?
[root@ForeignLinux ~]# gccgo hello.go -o test /tmp/cc06PbMI.o: file not recognized: File truncated collect2: error: ld returned 1 exit status
https://wiki.archlinux.org/index.php/Go
anyone experienced this?
I don't understand what this is supposed to accomplish. What's the advantage of building on GNU/Linux and running on Windows compared to building on Windows and running on Windows? Seems like it's needlessly complicating things making a binary compatibility layer.
It's trying to accomplish exactly the same as Wine, only vice versa.
There is a considerable amount of software written and compiled for Linux that is not available on Windows.
There is a considerable amount of software written and compiled for Linux that is not available on Windows.
For people who are required to have a machine that boots into windows because of corporate policies at work maybe?
Unfortunately seems to crash immediately on Windows 10 Tech Preview (build 9926). It's what I can expect for using a prerelease OS though.
Edit: It looks like this might have been something on my end. Re-downloaded and extracted and it seems to be working now.
Edit: It looks like this might have been something on my end. Re-downloaded and extracted and it seems to be working now.
[deleted]
Personally I have been using Scoop with ConEmu. I find that is enough for most things :)
http://scoop.sh/
http://www.fosshub.com/ConEmu.html
http://scoop.sh/
http://www.fosshub.com/ConEmu.html
this is the exact opposite of WINE, implements linux sys calls in windows
Midipix is due soon and provides a system call interface for Windows and a Linux libc.http://midipix.org/
Does this support running X over SSH? The biggest drawback for me with Windows boxes was always a lack of X support for applications I want to run on remote servers.
Yes. From the stock bash prompt, run "startxwin". With the resulting xterm, you can launch any X apps within Cygwin, or you can SSH in (with appropriate flags and xauth config, etc.) and blow back X apps from the remote Unix box. It's really nice.
In my limited experience, Xming worked fine for that use case.
interestingly I wasn't able to run vi, but could run vim. I reported to the github issue tracker.
This seems very neat. Definitely much less overhead than VirtualBox. Plus can write to the same filesystem as windows without windows admin privileges (which can be done with cygwin, but not with virtualbox). Once it supports x86-64 binaries and threading and users, this could be very useful.
This seems very neat. Definitely much less overhead than VirtualBox. Plus can write to the same filesystem as windows without windows admin privileges (which can be done with cygwin, but not with virtualbox). Once it supports x86-64 binaries and threading and users, this could be very useful.
So this is the opposite of Wine for Windows?
Cool. CoLinux does something similar
I thought that CoLinux was actually running Linux as a service in the NT microkernel (like MkLinux on Mach), rather than just an executable compatibility layer.
I thought it's been dead for ages
This is one of the things that's always driven me nuts on Linux, and also one of the things I really like. Some projects that are interesting like this seem to disappear for a while, but often the concept will be resurrected under a new project. CoLinux is one of them, UserFS (now FUSE) is another one that went away for a couple kernel versions and is now back. I'm still waiting for an SSI (single system image) to make a comeback though (Mosix, OpenMosix, OpenSSI, but none of them work with newer kernel versions).
That's like Wine in reverse?
very nice project! I hope it takes off
running applications on cygwin can be a pain
What this tool offers over Cygwin is the ability to run unmodified linux binary-only software for which you do not have the source code. For me there's not very much of that although i release some at $DAYJOB.