41–50 of 96 posts
Earlier quoted context omitted.
Cygwin doesn't rot. It doesn't automatically update, and nor does it self-configure, so there's nothing to cause the rot. I've never had problems like you describe. The biggest problem - and what I suspect is happening to you - is when you have third-party programs and utilities that interfere with Cygwin, most often by putting an older or newer version of cygwin1.dll on the $PATH (i.e. you may be using Cygwin as par…
"there's nothing to cause the rot" The rot tends to set in as I install packages to Cygwin; the more I add, the slower and less stable Cygwin seems to become, to the point of taking tens of seconds to reach a prompt after opening. Make of that what you will. "Also some antivirus programs can trip up Cygwin" That could well be a contributing factor in my case.
[1] http://cfc.kizzx2.com/index.php/tag/cygwin-slow-performance-...
Earlier quoted context omitted.
Do yourself a favor and don't lock yourself even more into the Windows environment if you, for whatever reason, have to work with it.
May I ask why?
These jumps in "technology" are perhaps forward, but also very much backward. I've seen it time and time again with clients who have bought a new computer and had to deal with growing pains (and hatred) of the blue globe, ribbons, and other 'we changed the gui to make it hard to do what you previously did easily'.
At least in the Linux world, your knowledge isn't decimated on an update. There may be depreciations, but those are rarer than MS "we update the world'.
Earlier quoted context omitted.
Really 14hours?! Have you tried to change the way the dump is done?
Well you can only pipe to file as the output is on stdout. We just ran it through cmd.exe instead. 8 mins is fine - it's a 12Gb repo. I assume it's related to PS converting every line into a system.string.
Is this different from Unix Utils? Every gig I've ever been on where I'm forced to use a Windows box, first thing I do is load the Unix Util exes into some directory and add it to the path. http://unxutils.sourceforge.net/
If you like unixutils, you might like GOW a bit more: https://github.com/bmatzelle/gow/wiki/executables_list https://github.com/bmatzelle/gow/wiki Kept up to date, every .exe (once installed) is self-contained (no external .DLLs) and portable to just about any Windows box I've run into. No Cygwin or MinGW installation required. Bash is actually available in the list (albeit an older version) if you really wanted "bas…
The initial github commit has comment "Initial import of the code I developed back in 2006. Nothing has been changed since then.", and nothing has been changed since that commit (with exception of docs, Gow.nsi and gow.vbs files).
Earlier quoted context omitted.
"there's nothing to cause the rot" The rot tends to set in as I install packages to Cygwin; the more I add, the slower and less stable Cygwin seems to become, to the point of taking tens of seconds to reach a prompt after opening. Make of that what you will. "Also some antivirus programs can trip up Cygwin" That could well be a contributing factor in my case.
Did you try disabling bash completion[1]? [1] http://cfc.kizzx2.com/index.php/tag/cygwin-slow-performance-...
I haven't bothered re-installing cygwin since the last nuke-and-pave, but I'll bear that in mind if I do and it's still relevant.
Earlier quoted context omitted.
May I ask why?
Many a times, Microsoft will retire the older methods for something blazing new, and ruin what application knowledge you had in the process. These jumps in "technology" are perhaps forward, but also very much backward. I've seen it time and time again with clients who have bought a new computer and had to deal with growing pains (and hatred) of the blue globe, ribbons, and other 'we changed the gui to make it hard to…
It's funny that this should come up in a thread about PowerShell, a replacement shell Microsoft released 6 years ago which still hasn't supplanted cmd.exe (which itself is based on syntax from the late 70s).
Earlier quoted context omitted.
While powershell is a valuable and interesting option, the problem with it is that it changes the basic metaphor. For 40 years unix shells and their descendants and derivatives including cmd.exe have used files and text streams as the metaphor for interconnecting processes. Powershell changes that, and it means the output of one command goes to the input of another command as "objects". This can be powerful, but it i…
I'm not a fan of powershell but I have to use it in my line of work. The only thing that I find sucks is that the pipeline is slow as snails. For example, an svnadmin dump piped to a file which takes 8 mins in cmd.exe takes 14 hours in powershell... Apart from that it's bearable!
This is because CreateProcess in Windows is slow. It's the reason that run make on Cygwin on Windows for not-that-large Makefiles is really, really slow. The same Makefile on UNIX and Windows differ in startup time by a wide margin. It's really painful to type "make ..." and sit there for 30 seconds on a fast machine.
Do yourself a favor, learn PowerShell if you have to work on Windows. http://technet.microsoft.com/library/bb978526.aspx
While powershell is a valuable and interesting option, the problem with it is that it changes the basic metaphor. For 40 years unix shells and their descendants and derivatives including cmd.exe have used files and text streams as the metaphor for interconnecting processes. Powershell changes that, and it means the output of one command goes to the input of another command as "objects". This can be powerful, but it i…
You even get autocompletion across commands: if you type "ls | sort _" where _ is the cursor, then you get a list of properties that you can sort objects returned by ls by (LastAccessTime, LastWriteTime, Extension, etc).
Earlier quoted context omitted.
I'm not a fan of powershell but I have to use it in my line of work. The only thing that I find sucks is that the pipeline is slow as snails. For example, an svnadmin dump piped to a file which takes 8 mins in cmd.exe takes 14 hours in powershell... Apart from that it's bearable!
The only thing that I find sucks is that the pipeline is slow as snails. This is because CreateProcess in Windows is slow. It's the reason that run make on Cygwin on Windows for not-that-large Makefiles is really, really slow. The same Makefile on UNIX and Windows differ in startup time by a wide margin. It's really painful to type "make ..." and sit there for 30 seconds on a fast machine.
svnadmin dump d:\repo > repo.dump
Effectively where *NIX shells use a fixed size buffer for pipe operations and operate on streams, PS has to convert it to lines first before writing it out.
That doesn't work when you have approximately 25 bytes per line and a 12Gb file which is where the issue is.