Live data from Hacker News

Gow – The lightweight alternative to Cygwin

github.com

11–20 of 95 posts

Re: Gow – The lightweight alternative to Cygwin

#11
post #5

What is the use case for Cygwin in the days of virtualbox/vmware?

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.

Re: Gow – The lightweight alternative to Cygwin

#14
post #12
post #5

What is the use case for Cygwin in the days of virtualbox/vmware?

Cygwin gives you (seamless) access to the Windows file system. Is it possible to (say) 'sed ... | wc' a file in the host's directories from a VM?

yes. for example in virtual box you can mount host's directory tree within the vm either in rw/ro mode. from then on, things are seamless.

Re: Gow – The lightweight alternative to Cygwin

#15

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.

Re: Gow – The lightweight alternative to Cygwin

#18
post #15

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 ba…

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.

Re: Gow – The lightweight alternative to Cygwin

#19
post #17
post #3

Is there an SSH server for Windows that will work with this?

Or an SSH client which can be called by the gow shell?

In reply to both yourself and guan, the answer is openssh: http://sshwindows.sourceforge.net/

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.

Re: Gow – The lightweight alternative to Cygwin

#20
post #5

What is the use case for Cygwin in the days of virtualbox/vmware?

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.

Post reply on HN