Cygwin is impressively complete - if you haven't checked in on it recently, there are over 5000 packages in the official repo (that's more than Arch Linux's official repos), and adding the http://cygwinports.org/ repo gives you full KDE, GNOME 3 and Xfce on windows (although KDE has a first-party port).
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
> 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.
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
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."
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'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.
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.
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 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.
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 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).
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.
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.
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)
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.
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.
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!
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....
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.
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.
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.
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 :(
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.
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:
sls "Pattern" file.txt | select -exp line | out-file t.txt
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.
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".
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?
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.
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.)
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.
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)
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.
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.
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...
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).
"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.
> 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).
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.
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 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 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.
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.
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.
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.
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).
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.