Can we go together and convince the stubborn Cygwin-devs to PLEASE integrate this into mainline? I've tried a couple of times to convince them that we need something like apt-cyg, and lots of people keep trying, but they just won't budge.
Like 10 years ago, I was poking them at the idea of having some command line support for package installation instead of having to go through the brittle setup.exe to install/update packages... You can make an educated guess at the answer to anything related to non-retarded package management.
Cygwin is a great tool. I've used it for 15 years.
Its installer has always been ... lacking.
The example of non-broken installers, in the form of RPM (from Red Hat, with which Cygwin is now associated), or APT (from Debian, even non-broken than RPM) has been around since, oh, 1994 or so (apt really came into its own a few years later, but since 1997/98 it's been a pretty amazing tool).
The development of apt-cyg has already been done.
A key element of managing any project is to be responsive to constructive criticism, and accepting of outside ideas. Especially excellent, long-desired, well-constructed ideas instantiated in code.
I'm taking statements here at face value, but if the response of the Cygwin team has been "thanks, but no, your 'good' isn't our 'perfect'", then they're 1) being butt-retarded and 2) reiterating one of the classic blunders.
Fortunately I don't particularly care, as I've made pretty clear in this thread, my need and use of Cygwin is pretty minimal these days, though on the very rare occasions I find called on to use it, yes, I appreciate it.
Raising devs beyond criticism, BTW, is yet another classic blunder. It's one the GNOME team have been perpetrating for over a decade now -- tech-savvy users aren't it's "target userbase", and non-tech users are, by definition, "unqualified to comment on code". So they've derived by circular logic that those qualified to comment cannot comment relevantly, and those who can comment relevantly aren't qualified to comment.
The project's malaise over the past few years has hardly been a surprise to me.
I'm not saying Cygwin are falling quite so hard into precisely the same trap, but they're clearly making an error here, as are you in dismissing criticism.
I'm not raising the cygwin devs beyond criticism. I don't even think they themselves do this, at least not in the way that you describe gnome (which is a point well taken). I think that this small handful of smart developers are more influenced by their own personality than a larger more inclusive group might be, and their interaction, as I have observed in their response to requests and criticism, is somewhat abrasive. "Curt."
I don't worry about it, because I can't play in their sphere. I'm happy to have it, like I'm happy to have gravity, and I can't change or influence either one.
The installer actually has improved incrementally over the years. apt-cyg would be nice, but it's reasonable for them to triage it off the list of things to do, since anyone who cares can install it themselves.
I'm one of the cygwin developers. Please feel free to discuss the inclusion of a new package in the cygwin mailing list. If there is an active maintainer for the package and the package works as advertised, then it is possible that it would be voted in.
It would be inordinately useful if you could refrain from name calling during any discussion.
As others have pointed out, Gow isn't really a Cygwin replacement; it offers over a hundred *nix apps compiled as native win32 binaries. A similar project from yesteryear - might be of some small use to one or two people (max):
The Berkeley Utilities - 40 unix commands ported to DOS
http://web.archive.org/web/20090304003628/http://openetwork....
"The Berkeley Utilities follow rigorously the unix System V syntax and include all the options found on any unix system plus a few carefully chosen ones. They used to sell for $200 and are now free." Great documentation, but sadly no source.
So it's been posted again, 186 days ago. So what? Not everyone visits HN every day, and not everyone's been here since the beginning. Reposting useful stuff for those who might have missed them is a good thing in my book.
This is how everyone defends reposts, but for an experienced engineer that's been reading HN for a while it means the front page is often full of uninteresting links.
But to prevent reposting, the poster -- who doubtless missed the original posting -- would have to search somehow for previous HN posts about the URL. But there is no search facility on HN. You can't blame the poster.
Stating that there is no search box on HN is a.) incorrect and therefore b.) adding nothing to the discussion - so it seems to fit the criteria for downvoting.
Downvotes don't have to indicate "I'm punishing this user", they can simply be "this comment is low-value".
That's a fair argument. A solution would be to increase the initial weight for same link posts every time they're posted. That would decrease the time they spend in the front page exponentially.
You could easily bypass this, of course, but I don't think most people are trying to hack the front page, they just found something interesting and they're sharing it with us.
I'm pretty sure this is wrong. I think what you're talking about is HN's filter that prevents you from posting a story whose URL is identical to the URL of a story that's currently in memory. If you try to submit a URL that's already in memory, it gets converted to an upvote for the original.
That doesn't prevent you from either posting the exact same URL once the original story has been purged from memory (probably after a couple of weeks) or posting a slightly different but completely equivalent URL. For example, IIRC the following are all counted as different URLs:
Such is the circle of (mailing list/forum) life. Over time, new people join, read, and eventually contribute, some of which is a repeat of content that occurred before they joined. Over this same time, established people get ever more disgruntled over repeated (to them) content and leave and become a new person in some other list/forum.
BTW, Windows PowerShell includes a bunch of unix aliases including ls, cat, cp, mv, rm, pwd, more, ps, man, mount, echo, diff. It is also very customizable, it became my standard windows shell when I discovered posh-git https://github.com/dahlbyk/posh-git
If Microsoft had wanted to do the Right Thing, they would have adopted the bash shell, and created a set of utilities providing access to services it doesn't provide.
Currently, Bash (or something very bash-like) is The One True Shell for all Unices, Linux, MacOSX, and even (rootkit ant terminal app) Android. As well as zSeries and numerous other platforms with appropriate compatibility kits.
Microsoft are ghettoizing themselves. It's a large, well-populated ghetto no, but I see a downward trend.
There is "SUA", but it's only available for the Enterprise & Ultimate Windows editions. (And supposedly going away entirely after Windows 8.) Shame it wasn't better integrated and packaged.
There is also UWIN which emulates a full Unix environment for windows. It includes KSH. Its cc comand can work with a number of compilers including MinGW, and Visual C++.
I fail to see how this is interesting. There is already a well known alternative to Cygwin: MinGW/MSYS. Also, anyone looking for such a thing can find it with five minutes of googling.
I've been using GNU-Win32 for years; it's generally solid, and the CHM docs are nice, but there are some issues with it. But last time I was looking for a replacement, I couldn't find one! Gow looks like it might be just the ticket.
As for MinGW/MSYS, last I looked, MSYS looked a bit incomplete for my purposes. I don't have any interest in or need for the MinGW gcc and autoconf bits, which tools looked to be its main advantage over GNU-Win32.
I thought the same. Then I found that Gow is shipping way older versions for many binaries compared to GNU-Win32, and its patch.exe causes UAC prompt for non-administrators.
GNU-Win32 is solid, integrates natively, and is good enough for deployment purpose.
That's great! But it seems it's more like GnuWin32 rather than Cygwin. Cygwin provides very compatible POSIX system call API (through Cygwin DLL) in terms of Win32 system calls.
Cygwin goes to heroic lengths to try to turn Windows into Unix; from what I've heard, it even splices a DLL into every process on the machine; if you want a less intrusive solution that just gives you a Unix utilities under Windows, Gow looks good.
Cygwin processes run through a shared DLL, of which one significant consequence is that all Cygwin processes on a machine apparently share some memory/process segments, making crypto and SSH commands less secure than they might be elsewhere.
That said, the heroic efforts to turn Windows into Unix, when on the rare occasion I find myself stuck in a Windows instance, are very highly appreciated.
At one point in my life, I was taking advantage of this to run X on my Linux box (cleaner and a few additional features that Windows didn't offer), with tunneled SSH to Windows to run, among other things, some Windows-based applications (which retained enough commandline features to be usable in this fashion) in an environment which almost fully resembled Unix.
It helped markedly for both productivity and sanity.
Afraid not, I forget where I heard it. I ran a Google search just now, though, and found a few pages such as http://forum.bitdefender.com/index.php?showtopic=15070 which suggest Cygwin is innocent of such behavior and what's really going on is Cygwin needs a fixed DLL address (only for programs linked against it) and this is not compatible with some of the more intrusive antivirus programs that do inject a DLL into every process.
Gow appears to automatically make all those Unix utilities available right inside the normal Windows command line without having to manually kludge them in there like you do in Cygwin. I usually just find myself missing the kinds of utilities that are included in Gow, so I don't really need the entire Cygwin universe available. The fact that I can download and have it installed in 15 seconds and get 99% of what I would like added to Windows will make me choose it by default when I have to work on Windows.
Adding the "Command line here" context menu item is nice, too (although that's available by Ctrl+right-click in at least Windows 7 anyway).
I ran cygwin and mingw on win32 for nearly a decade. Switched to Ubuntu earlier this year, never looked back. I write 100% portable code for work; write on Unix, deploy on everything. Even our accountant's Excel macros work for me in LibreOffice. Absolutely do not miss Microsoft Windows, good riddance.
I think with today's machine power we're reaching the crossing point where this is becoming a practical preference.
Yet I still run cygwin at work. Partly I think it's because we still use XP, and I don't get to throw as much memory and video at VirtualBox as I'd like.
Opening a native console is notably faster and lighter than booting a VM. Interacting with real system files, network ports, etc. is also much more convenient and less error prone than setting up shared folders and other trickery.
If you're doing any real work in a console on Windows then you're in a world of hurt. The console itself is just awful compared to what you have available on a real, POSIX-compatible OS (Linux, OSX, etc).
This extends to SSH apps, too. Putty? Seriously? And implementations of tabbed and paned shells (the few you can choose from on Windows) are terribly ugly and clunky.
Windows 7 (and presumably 8) is a fine OS. I really had no beef with it. But as an engineer I spend far too much time at a command prompt to ever consider going back.
Also -- you don't boot your VM every time you want to use it. You keep it running in the background. Allocate 256MB of memory to it and forget it until you need to use a real shell.
Lighter in what way? I don't necessarily disagree but when I think putty i think:
No tabs and No panes so you're limited to using the OS window manager, and if you want to achieve multiple usable sessions at once you're going to have to arrange and resize these windows yourself or you'll have to use another 3rd party app.
No integrated private key authentication. You have to use like 3 GUI screens (wha?!?!?) to set this up and then you have to run a 3rd party app like pageant.
I had many other gripes before I switched (to a mac in my case) but I can't remember them anymore.
I do have Cygwin installed but anyways I have been using Gow for a couple of months already. Thanks to it I can still run `grep` and `less` when I am using a normal DOS terminal (or even 4nt) for example when I need to run a build script.
There is still some grasps with the shipped versions of the tools i.e. missing some parameters and not having `awk` is a bummer.
I've always found the DOS terminal to be very dissatisfying. I recall when I first encountered WinNT40WS, which a colleague had billed as "a multiuser OS with a full shell", that, other than the lack of a full shell and useful utilities (I rapidly discovered MKS, UWIN, and Cygwin, followed very shortly thereafter with Linux, which supplanted the original OS a few months later), was the absolute crap terminal support.
That this is still the case (from my relatively minimal experiences/exposure to Win7) can just be piled on top of the large heap of embarrassments Microsoft have produced).
When installing Cygwin, among the first things I do is create a shortcut using the rxvt (non-X) client, with a command to launch a log-in shell session, with appropriate font and color settings. You can even run Windows commands and shells within this, though of course, they will also break in some full-screen instances.
Mostly I just avoid the whole problem. Pretty successfully for months at a stretch these days.
MinGW comes with an installer that gives you GCC. Make sure you install MSYS as well (comes with bash, etc). Add the bin directories to your %PATH% when you're done. Then set Console to use bash as your default shell, and you have a pretty close setup to the command-line experience of Linux/Mac.
That's one of the draws, sure. But it's also nice to be able to replicate shell scripts or clever unix file hacks with a complete set of syntax compatible utilities so that less "translation" needs to happen. If you don't need all that back-end compatibility stuff (running gcc, etc.), this can be a much quicker and easier approach.
Shell window from any directory: Adds a Windows Explorer shell window (screenshot) so that you can right-click on any directory and open a command (cmd.exe) window from that directory.
Hmm... but.... why would I wan't to do that? If it opened a window running bash that'd be interesting, but I never ever want to run cmd.exe if I can possibly avoid it. Perhaps that's just me though... can anyone comment on how this compares to cygwin, generally? I see that it's smaller but I don't find cygwin's footprint especially troubling.
Windows provides this feature natively, since Vista or 7 (I don't remember which): when you shift right-click in an explorer window, the option 'Open command window here' appears.
I'm not seeing that on this fairly fresh Windows 7 "Pro" install.
I have added the feature to numerous Vista and XP machines, it is easy enough to add manually though there are many utils that will do it for you, but I can't say I've never seen it present by default.
I had 2 people check for me, one with 7 Home Premium, one with 7 Ultimate, in addition to my own 7 Ultimate; all had the feature I described; none had added it manually.
If you don't need to run cmd.exe, then this is likely not for you.
On Windows, I deploy native 64-bit Python, and the application has quite a few command line pyramid scripts, which works perfectly fine with grep, cut, sed, sort, etc from gnuwin32. Don't see the need for cygwin.
> If it opened a window running bash that'd be interesting
Cygwin has a package for that called chere. The whole point of this other thing is that it tuns in cmd.exe, so complaining that it opens cmd.exe is really complaining about the main thing, not just this one feature...
I would want to do that to run a batch file, see the output.
I have, for example, an integration server, Server 2003. It keeps batch files for XML to JDE eleventy directories deep. It is sometimes helpful to exec these manually to see what the trouble is.
I've long had poor feelings about Cygwin being slow and a poor solution. I wanted something that didn't try quite so hard to completely distance itself from Windows.
So, instead, I've been using MinGW's msys project. I don't think it is quite as small, but it does offer a package manager.
One small thing in msys that I particularly like is that I can do thins like:
cd //server/share/some/directory
I never saw powershell or cygwin do that. On Solaris I can configure automount to do that which is good enough, but just working is also nice.
I miss andLinux and coLinux. Since using a 64 bit OS they no longer work, but they natively emulated the whole Linux kernel and offered a pretty integrated solution. Not lightweight by any means, but just what I wanted.
