I understand why someone wouldn't like to use cygwin, but why new project?
MSYS/mingw-get are active projects that provide a good base to build upon. Why not helping improve it? Unix tools on Windows is niche enough so that choice only leads to fragmentation, not competition.
This is exactly what I also thought when I read the headline. And this becomes even more strange given that they are almost certainly building upon using MinGW.
Cygwin is not perfect, but he's the thing that I prefer over other options.
It's unix emulator layer, and as such tries it's best to emulate fork() - which the other alternatives does not even think to put in.
VM is not a real alternative, as there is actually more work to be done to plumb source A with tools B from the VM.
I don't use cygwin from bash, but rather start it directly from the FAR manager (console based Norton Commander/Midnight Commander application for Windows). It's very useful, as a lot of commands just work.
Then there are others, which are some kind of symlink (one of the downsides of cygwin for me), but that's understandable. Symlinks as they are on linux are just starting to appear on Windows Vista and 7 (and I'm not even sure how compatible they are).
So for such cases, sh -c would work. For example checking out latest SDL using cygwin, but from the command-prompt:
c:\p\sdl> sh -c "hg pull -u"
And then other stuff works even better:
c:\p\libzmq> git pull -u
c:\p\libzmq> sh -c "gitk --all"
Thanks a lot! SysInternals, NirSoft tools and anything that I can find for Windows is very very much appreciated. (At home I'm sticking to OSX and Ubuntu, but at work the situation is rather different - I'm often finding myself arguing with myself - at home I prefer gnome/gtk, at work I better stick to Windows.Forms, hehehe).
I find it strange that no one is mentioning UWIN[1], started by David Korn about the same time and with the same goals as Cygwin.
I used to use it. I liked the fact that it used the host compiler instead of gcc, plus I preferred the non-GNU tools.
Now I'm using Inferno, it works much better. It's not Unix, it's Plan9, but I view that as a plus. Of course cygwin can install all kinds of Unixy tools, like gcc, openssh, xterm and whatnot. Inferno doesn't come with anything, but I don't need anything except the basic Plan9 tools.
You run Inferno on top on Windows as an application? I have read that this is possible but I have never seen anyone doing this, not even in a screenshot. If so, what's your opinion of it as an environment?
(By the way, Inferno's implementation reminds me of Niklaus Wirth's Oberon, which could also run as either an application or as an operating system.)
Yes! Inferno can run both native, on the bare hardware, or hosted under Unix, Windows or Plan9. Most people run Inferno hosted because it's easy and you can benefit from the host operating system services as well.
For me, it's the best environment because I can have Acme (the editor), Plan9 name spaces and the Plan9 tools which I am most familiar with on any operating system I use. You can use either full Inferno [1] or Acme SAC [2]. Hosted Inferno runs in a window, which feels awkward to me, so I use Acme SAC which is a native host window and I run the shell inside Acme. Acme is the only graphical Inferno program I care about anyway.
I was about to ask the same question. MinGW is already the lightweight alternative to Cygwin, and has largely taken over for the task of compiling unixy things on Windows.
The major difference between MinGW and Cygwin is MinGW tries to use native Microsoft libs by dummy wrapping them (like, MS's libc is often compatible with POSIX standard stuff, the POSIX version merely starts with _ frequently, MinGW uses this fact).
Most stuff that won't compile "natively" on Windows through Visual C's compiler, those projects use MinGW, I never hear of anyone using Cygwin especially because of the requirement of shipping the Cygwin runtime dll (of which MinGW has none).
Even Strawberry Perl, the Perl distro for Windows, uses MinGW to compile XS perl modules from CPAN.
I recently decided to learn ed, as I felt it couldn't hurt to be familiar with it, and I was surprised to see that it wasn't installed in Arch Linux by default.
If one has bash as the default shell, why not ex as the standard line-oriented text editor?
Postscript - ex is the version of ed rolled up in vim, which extends the command set of ed. vi, by contrast, handles colon commands by invoking ed externally.
"ex is the version of ed rolled up in vim, which extends the command set of ed. vi, by contrast, handles colon commands by invoking ed externally."
Actually vi and ex came about at the same time. You can see the POSIX standard mentions [1] ex and vi (not vim) together, and you can also refer to [2], under the "First appeared" column.
Indeed, there is a mistake in what I wrote. What I should have said is that Bill Joy wrote ex, and then he used this implementation to write vi. Vim is like vi in that it comes with an ex built in, which is an extension of Bill Joy's ex.
IIRC, I became interested in ed after reading about the Plan 9 editor Sam, which was described as "ed on steroids, lots of steroids"[1]. Sadly, I never got around to trying Sam.
We really need to port Homebrew to Windows so that projects like this can be the base, but people can pull in packages on top of it, like a lightweight Cygwin but more Windows'y.
Does porting Homebrew make any more sense than porting something from Linux (for example)? My impression is that the Mac OS ones aren't as good.
A package manager really sounds like the sort of project where the incompatibilities between *nix and Windows are large enough that writing a new one would make more sense. I think there are even existing projects like that for Windows; I remember seeing one on HN a while back, but can't recall the name.
The advantage of Homebrew is that it is modern, small, and simple. Obviously apt is better, but apt also requires that you maintain a large repository of binaries. Homebrew is slow[1], but because it builds from source it is trivial to create a new package. Homebrew packages are just Ruby files. If the project uses Autotools, all you generally need to do is enter the URL, an md5, and the dependencies, then it Just Works. If it uses waf or something it's still just a simple modification.
Instead of reinventing its own selfupdate functionality, Homebrew just uses git. Updating Homebrew is really just fast forwarding a git repository. Finally, the maintainers explicitly do not duplicate the libraries/tools that ship with OS X.
This is a big step up on OS X from Macports, which installs itself in /opt/local and rebuilds everything possible. Homebrew is instantly understandable. Packages are files, you just match them by name. apt is admittedly more complex, but at least you get something for that complexity.
[1] really what's slow is building from source. Homebrew itself is very fast.
Everything you just said (packages are files, simple, uses existing tools for self update) applies to MacPorts too. The only real differences seem to be the use of Ruby, and an attempt to avoid replacing OS dependencies -- even if the replacements are newer.
In fact, MacPorts actually supports generating Debian packages and an apt repository straight from its port files.
As for Windows, Cygwin already provides binaries. An apt repository of them would be great. I'm not convinced porting homebrew or MacPorts makes sense, however -- they're both fairly Mac-focused.
Macports builds something of a sandbox, which from the users point of view is neither small nor simple.
It is easier for the Macports team to make sense of bug reports with a sandbox, however, which is, I assume, why they do it. It is explicitly the reason they forbid installing to /usr/local.
Macports used to not build this "sandbox", but learned the lesson that relying on Apple as your only source of updates to critical base libraries was fraught with peril: not only do you not get updates you might need ("upgrade to 10.6" is not a reasonable response to someone who just wants to use a project that needs a slightly newer version of libcurl), but sometimes Apple can ship changes that break compatibility without realizing it (as they were not using that part of the library). Once you start dealing with this complexity, the sandbox is actually much /simpler/, as you get well defined results: the only variability are changes in kernel behavior, which tend to be a much less shifty target.
The "sandbox" increases the complexity of the system that the user deals with. The other notion of simplicity is one that should matter only to the Macports developers.
I do not like to criticise open-source projects, but the (reasonably polite) hostility that stating this simple fact has attracted does make me think that the supporters of Macports have stopped seeing things from the user's point of view.
If you want a packaging system whose job is to protect you from the risk of certain rare but possibly messy mishaps, then Macports might well be what you want. I recommend being less risk averse, and use a mixture of Homebrew and installing to /usr/local. It will cost some research and reinstall time now and then, but it will result in a system that is easier to get an overview on.
The talk I have seen of "destroying" one's system installing via Homebrew is pure FUD, and I do not know what lies behind it.
As a user, I find knowing that "install X from MacPorts" should always work, no matter what underlying version of Mac OS X I have, can always be up to date with the latest features, without having to update Mac OS X, and won't fail when I /do/ want to upgrade Mac OS X, the definition of "simplicity".
(Honestly: what does Homebrew make simpler than MacPorts anyway? Near as I can tell, the only reason people seem to like it is that it doesn't take as long to compile software, which argues more strongly to me that we need binary distributions that can download pre-compiled copies than that we should attempt to use the libraries to save installation time.)
1. No alternative copies of Python, Perl, Ruby, zlib, etc...
And if I need a newer version of Python, coupled with a dependency tree of third-party modules?
I don't see why this matters, other than some pedantic sense of cleanliness ("NO DUPLICATES!" ... even though they're not, in reality, duplicates).
2. Everything installs to where it is supposed to, i.e., under /usr/local/
You can configure MacPorts to do this, but the reason it's not the default was to leave /usr/local for the user's own manually installed software. I don't think this really matters either way.
After installing via Homebrew, things do not look drastically different to having compiled them by hand.
Are you perhaps thinking about the CoApp project? It's making some decent progess, check out CoApp.org for updates. Last I heard they were in the process of shallow-forking a slew of OSS projects and building them natively in Windows.
"apt-cyg is a command-line installer for Cygwin which cooperates with Cygwin Setup and uses the same repository. The syntax is similar to apt-get. Usage examples:"
"apt-cyg install <package names>" to install packages
"apt-cyg remove <package names>" to remove packages
"apt-cyg update" to update setup.ini
"apt-cyg show" to show installed packages
"apt-cyg find <pattern(s)>" to find packages matching patterns
"apt-cyg describe <pattern(s)>" to describe packages matching patterns
"apt-cyg packageof <commands or files>" to locate parent packages
pkgsrc already supports Windows Services for Unix, it may well work on top of this too (though I haven't looked at Gow yet and I honestly have no idea how it differs from MSYS).
But when I think "Unix-like core plus package management on Windows"... well, Cygwin is already there.
SFU/SUA only work on enterprise/ultimate versions of Windows. Also, pkgsrc is reported to work, but who actually tries it know it works pretty bad and it requires lots of manual patching.
Well for a far more light weight solution there's GnuWin32 and GetGnuWin32 (which installs GnuWin32), both available via an easy Internet search. They both run from the command prompt and you don't need any other environment for them.
This is not an alternative to Cygwin, and shouldn't be called such.
Cygwin isn't a collection of binaries; that's a distribution. But the idea is to emulate UNIX, including fork(), etc., allowing you to easily recompile for Windows.
Would be good to have a standard ssh client similar to the ones in linux and other unixes. I use Cygwin mainly for that. I do not want to do putty -ssh ... and I want to copy my keys and other config in ~/.ssh. Like that I can "standardize" the way I setup my accounts on cygwin and linux. Without that it is kind of a big hassle
KpyM seems to do a decent job of providing SSH access to a cmd.exe prompt (and anything you care to run from one). It's free although the provided binaries do an annoying nagware thing on login. I've been using it for SCP access to Windows servers.
Semi-related: PowerShell Server, a commercial Windows SSH server with a free restricted license (notably a single connection and only password authentication):
While it is built with cygwin, I believe it's statically linked to get rid of the dependency hell. You don't have to take into consideration that it is a cygwin binary.
I can no longer edit my answer, but I just downloaded it and extracted the setup archive - you're right. OpenSSH for Windows is not statically linked to cygwin.
I do, however, still think it's possible to statically link OpenSSH with Cygwin, in which case it would become the answer to the original question.
1) if you want to program in "gnu", run unx, and if you want Windows as your host OS, run virtualization;
(yes, you need 8G, yes, you should have an SSD, if you don't, buy a new laptop for $700 and run linux native)
Being able to use a real shell with all the tools I'm used to when developing on Windows.
Cygwin in combination with MinGW and the Windows native version of GVim lets me have almost exactly the same environment as I do on Linux and Mac OS X.
I don't see Cygwin as a file manager but as another (better) interface to Windows. A Linux VM wouldn't let me natively run and debug Windows software, which is the entire point of me being in Windows in the first place.
Using Unix utilities (including Unix paths and forking semantics) on your Windows system. I regularly use Unix utilities to e.g. manage Windows processes; frequently, when a game crashes and leaves me with a blank screen, I can blindly alt-tab to a terminal and 'killall foogame', or if it's worse, ssh in.
I use Cygwin to get approximately the same terminal environment in Windows as I do in Solaris, Linux and Mac. I have a suite of scripts to massage platform differences (e.g. Cygwin getclip / putclip vs xclip vs pbcopy / pbpaste, or cygstart vs open vs gnome-open / xdg-open / etc.). It means that in the terminal environment, I'm equally at home no matter what the OS.
I run Cygwin in rxvt. Using a better terminal than a Windows command window is a must; until I started using rxvt, I didn't even live in bash. Rxvt / bash combo uses considerably less memory, less startup time and less disk space - my dual-boot macbook air has Cygwin installed in the Windows 7 partition.
Half-decent interop between the unix-y bits and the Win32 native bits.
e.g., you might want to have a mostly unix-style build process that uses VC++ as the C compiler, and run it all inside Visual Studio using a makefile project.
For certain definitions of seamless. Windows has a habit of messing up nix file permissions and sometimes things just don't work at all unless you do it on the Windows side.
Windows default filesystem is NTFS and it's pretty safe to write. I certainly wouldn't set up something like a server which relies on this, but for personal use or even a development workstation I think it's fine.
I guess it might be a good idea to first check the disk using Windows after something like a power loss while the NTFS partition is mounted. But apparently NTFS-3G (one of the NTFS drivers) can also use the journal to recover the filesystem after a power loss.
I work at a company that currently provides a 32bit version of Windows 7 (the reasons are somewhat unclear.) But the bottom line is that we have the 3gb max addressable memory problem. When I have eclipse, outlook, chrome, various other dev tools and whatnot open, I'm often near the limit, and adding VMWare player or whatnot would probably be too much. So that's one reason... Plus, I find switching back and forth between a vm and the host OS still somewhat slow/clumsy.
(Yes, I know I should get a new job...)
I like the idea of Gow. Anyone know if you can achieve middle mouse button pasting as when you have X11 under cygwin?
I'm a UNIX and Mac OS X transplant using Windows for embedded hardware development (almost all the tools are Windows-only).
I need a terminal from which I can operate on my Windows file system, but running an entire virtual machine is enormous performance-impacting overkill.
In my last job, I used colinux with Windows 7 and it was a match made in heaven. But when I moved, I had to choose the next best thing, which is Mac OS X, because of lack of support for 64-bit windows.
MSYS/mingw-get are active projects that provide a good base to build upon. Why not helping improve it? Unix tools on Windows is niche enough so that choice only leads to fragmentation, not competition.