3 ms·
Yeah, GNU/NT would have changed everything. Instead we got cygwin :-/
by hnfong 5y ago
Yeah, GNU/NT would have changed everything.
Instead we got cygwin :-/
- pjmlp 5y agoWindows NT POSIX subsystem was more like BSD/NT, basic effort. And SUA was also not much GNU related.
- CRConrad 5y ago> Instead we got cygwin :-/ I've only used what I think is a subset (of a clone or subset?) of Cygwin: "git bash". At two jobs, on two different Win 10 laptops now. Is the rest of Cygwin also as excruciatingly slow?
- remexre 5y agoMy understanding is that the general problem description for "this Unix program is really really slow when recompiled for Windows" is generally either "lots of small files is good style on Unix, but expensive on Windows," or "fork() is nearly free on every Unix, but potentially expensive in NT."
- pjmlp 5y agoThis UNIX program is slow when compiling to any non POSIX OS (Windows is not the only one), because well stuff like fork() has to be emulated.
- CRConrad 5y agoSorry, I still don't get it -- I don't understand what either "lots of small files" or "stuff like fork()" have to do with this. Are those really the reason that "git bash", a single command line interpreting shell, runs single commands like 'ls -l *.txt" or "cd ../../uncle_dir/cousin_dir" as if it was stuck in a mixture of tar and molasses? (Do any processes have to be forked to switch my pwd? And it wasn't really all that many .txt files! :-) Oh well, my entire data set is N=2, so anecdata rather than any wide-reaching survey; could well be pure coincidence. It just struck me as I started a new job last Monday, got a new Windows work laptop and started the arduous process of installing required (and allowed) software on it, how uncanny the similarities between corporate computing environments are... Right down to this apparent slowness on the MING-64 command line.