Foreign Linux: Run Linux binaries on Windows without drivers or modification
github.com
github.com
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.
Plus, having a working Bash with everything I want on Windows blows my mind.
I like to say Cygwin "civilizes" Windows.
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).
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.
1: https://github.com/transcode-open/apt-cyg
EDIT: changed to github url
cd C:\distr\cygwin setup-x86_64.exe --no-desktop --no-shortcuts --no-startmenu --quiet-mode
Unless you are happy to spend your day in Visual Studio, in which case Cygwin will not be that useful.
--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
the problem was the 32 bit UEFI. Also solved: http://unix.stackexchange.com/questions/155557/installing-li...
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.
At least for my stuff that will run in Linux (node/iojs and golang) targeting docker containers, it works well.
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.
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.
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.
All I really find missing these days is good line-editing, and a half-decent terminal emulator in which to run the shell.
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):
On Cygwin, try MinTTY. The default cmd.exe console is horrendous. This is derived from PuTTY and much, much nicer.
And, you can also find MinTTY standalone separate from the burden of cygwin. I got it from the msys project.
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.
In this sense, it is better to compare msys2 with Arch packages, since msys2 uses pacman.
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.)
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.
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.
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!
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....
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.
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.
Now I feel horrible for revealing my dirty secret :(
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 "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).Line > t.txt
Select-String "Pattern" -Path file.txt | Select-Object -ExpandProperty Line > t.txt
sls pattern -path file.txt | select -exp line > t.txtAs an aside, you can replace the foreach with select-object for an efficiency gain:
sls "Pattern" file.txt | select -exp line | out-file t.txt (gc file.txt) -match "Pattern" | Out-File t.txt
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.
At a wild guess I'd say that's why you're "more productive with PS in a couple of months".
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".
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!
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.
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.
(Version 1.4, before Amarok turned to crap. I use Clementine now, which has a native Windows port.)
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 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 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.
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...
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"
Although, the "Support NTFS native hardlinks and emulated symbolic links" could be relevant if it does some magic there.
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).
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.
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.
[1]: http://cygwin.com/ml/cygwin-announce/2011-11/msg00040.html
[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?
There is a considerable amount of software written and compiled for Linux that is not available on Windows.
Edit: It looks like this might have been something on my end. Re-downloaded and extracted and it seems to be working now.
Disclaimer: I'm a Scoop contributor.
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.