On Aug 4, 2016, at 5:43 PM, Michel LaBarre <michel.laba...@rogers.com> wrote: > > Well my first foray into the world of CYGWIN mailing lists has been a lot of > fun so far.
You can’t expect to come into a well-established community and expect no push-back when you insist that they make a wide-reaching change just to suit your wishes. > Rather than replying to each respondent, I will try to respond to each in one > email. This may be a mistake. Yes, it is indeed a mistake. It breaks threading. Take a look at the thread view for this list’s mailing list archives: https://cygwin.com/ml/cygwin/2016-08/threads.html Replying like you have is tolerable at the time of the reply, because the thread participants have the context in their heads at that time, but someone coming along later and trying to follow the threads of the conversation get confused when all the threads get gathered back up like this. You’re making macramé out of our threads here. Stop it. > my perceived difficulty "in reporting an issue or comment" has more to do > with my not wanting to SPAM an entire mailing list. I think you don't understand how community support fundamentally works. The community support model only works when people post their problems publicly so that they can be archived and searched along with the public answers to those problems. That way, many other people can learn the answer in real-time as they follow the conversation, and still more people can learn it later by searching the archives. Thus, the person or persons who spent their limited time to answer the question benefit all those who read the answer, not just the person who originally asked. (The benefit to me from writing this very answer is to reinforce the mores of this community, not solely to educate you.) If you want to send private email to someone to get tech support, now you’re taking up that one person’s time for your sole benefit. That is a bigger “ask” than a request for public community support, so the benefit to the person replying naturally must be greater. In some cases, this means asking a friend with whom you already have a mutually beneficial relationship, and in others it means buying a support contract. This is why you generally see private tech support offered only by commercial software providers. Part of what you’re buying is the right to demand a slice of one person’s time for your sole benefit. > My expectation was that there might be a less pervasive mechanism to which I > could display my ignorance/confusion than the whole wide world of > cygwin-interested parties. That wish not to publicly embarrass yourself is what drives some people to search the mailing list archives before posting. Hint. Others take advantage of the phenomenon known as Cunningham’s Law, which is that the fastest way to get the right answer on the Internet is not to ask a question, it’s to post the wrong answer. See also https://xkcd.com/386/ > The fact that any/every issue gets communicated to everybody may explain the > "annoyance" evident in some of the replies I have received. No, the annoyance comes from insisting that your opinion is right in the face of ~20 years and millions (?) of users’ experience to the contrary. More importantly here is that your personal preference goes against the preferences of those writing the code. Open Source is a do-ocracy: those who do the work make the rules. Unless you’re going to fork Cygwin and change it to behave the way you want, you’re going to have to either accept such judgements as final or be more persuasive than you have been. Insisting louder is a poor form of persuasion. I believe I can best describe my feeling for your PATHEXT idea as ambivalence. I would not try to block it as an optional feature, but I would be irritated if it suddenly became the default behavior of either cygwin1.dll or Cygwin Bash. > ...to make the scripts equally natural to use within each environment. Have you considered writing a foo.bat wrapper for every foo shell script that you want to run the same in both environments? As I pointed out in a prior reply, the ability to have a “foo” command achieve the same ends via different means under cmd.exe vs Cygwin Bash is a feature of Cygwin, not a bug. Where you want the two environments to share an implementation, you can build some kind of bridge, as with my foo.bat idea, though there are certainly other ways to go about it. > Three isolated *nix-like environments have died under Windows - Interix, > POSIX subsystem under NT, and I expect Ubuntu under Win10 because of the lack > of integration with Win32. WSL left beta just this week, and you’ve already got its grave marker carved and installed? Wow. Microsoft replaced the POSIX subsystem with their Interix purchase because Interix was more functional. Interix/SFU died because it was first commercial — a speed-bump in the way of wide adoption — then it was only available in the more expensive versions of Windows, and finally, late in the game when it finally became a free download it still had all the interop weaknesses of NT subsystems, owing to the way the NT kernel keeps them mutually isolated. And yes, that isolation is going to be a speed-bump to WSL adoption, too. But, WSL has several things going for it that neither the POSIX subsystem or SFU had, the biggest of which are native ELF support and the Ubuntu package repository. I predict that WSL is going to woo away a whole bunch of Cygwin users who simply don’t need tight Windows integration. I predict that the biggest contingent will be web developers, since the only integration you need in that case is at the filesystem and TCP/IP levels, which WSL provides. For such users, WSL will be faster and a closer match to their eventual deployment environment than Cygwin, so it’s a clear win. Those WSL adopters will entrain quite a few others who might also be better served by Cygwin, all things considered, but who will use WSL instead because WSL appears somewhere else in their life first. > You can only do so much playing within a sandbox. Yes, but “so much” happens to amount to many billions of dollars worth of value to the computing industry, via virtualization, containerization, and sandboxing. Isolation is not always a bad thing. > Why would such product vendors be willing to pay big bucks for MKS if CYGWIN > is essentially free? Perhaps, the degree of integration with Win32 is part > of the answer. MKS predates Cygwin by quite a long stretch, so I’d bet a lot of their customer base comes from those they captured early on, and that they’re now living mainly off their prior lock-in, rather than any inherent value to the platform. How often do you see raw newbies saying, “Hey, I think I’ll go buy MKS instead of downloading Cygwin!” (Or Linux, or WSL, or anything else free.) Your argument reminds me of all the commercial Unix vs Linux flamewars of the mid 1990s. You saw how that went. It takes more than a few technical advantages to overcome “free and adequate,” and Cygwin surpassed “adequate” sometime in its beta stages. > Andrey Repin: Thank you for your insights. I fully appreciate the > difference between an O/S and a shell though it is apparent that your depth > of experience with low level interfaces exceeds mine and is much more current. Additionally, he’s part of the do-ocracy around here, so you’re going to have to at least take his opinions into account when planning what you’re going to do next. > After 41 years of working with Unix (starting with release 6 on 2 mag tapes > from Bell Labs on a PDP 11/45 with 256KB), in various > hardware/software/consulting companies in Canada and the USA, it still amazes > me that Unix has not swept Windows away. The Unix Wars did a lot of damage, as did all that time in the late 80’s and early 90’s when it took $1,000 to even get started with Unix on PCs. Then, as the Unix world was about to be saved from going down the drain by Linux and the BSDs, you had USL suing BSDI and SCO suing major Linux users. If the Unix world had gotten behind the OSS Linux/BSD movement as soon as it appeared, instead of waiting until they’d poisoned their own pond for a decade, we might never have lost the Unix workstation market and all the software that went along with that. The miracle is that Linux and the BSDs were able to rescue as much as they did. Without them, Unix would have slipped wholly under the waves a decade or two ago. Sure, we’d have had the occasional Solaris installation still chugging along, but that’s no more “continued success” than is the fact that there are VMS, OS/390, and OS/2 boxes still in service. Did you know that DEC’s VT terminal business was sold off to another company in 1995, and that they only left the business this year? http://www.boundlessterminals.com/ It takes more than an entrenched/imprisoned installed base to maintain a healthy marketplace. > easier co-existence with Windows might help enlighten potential converts You’ve got your cause and effect swapped. Cygwin is not pushing people to try Linux, the BSDs, or even commercial Unix. The explosion first of the web and then of cloud computing, driven by the availability of the free *ixes, is driving new users into the market for Cygwin. Therefore, the best thing Cygwin can do is what it is already doing: emulate Linux while doing the best it can to interoperate with native Windows. That order is key: where there is a conflict, Cygwin should follow Linux, not break compatibility or introduce behaviors that will be strange to the Linux/BSD natives just to make it behave more like Windows. > Powershell is great for C#/C++ programmers wanting a break but lethal to > admins/integrators/scripters. I don’t get PowerShell at all. It seems to me that it’s basically just a REPL for a dialect of C#. If I wanted to program in C#, I’d fire up Visual Studio. Microsoft promised me a better shell, not a C# REPL. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
