Re: run.exe will not work with upgrade from 1.14.4 to 1.16.3
On 2015-01-05 03:06, Laurens Blankers wrote: On 5-1-2015 05:04, Larry Hall (Cygwin-X) wrote: As far as I can tell, from the available information, users which meet any of the following criteria will run into trouble: - Custom .startxwinrc or .xinitrc Just .startxwinrc, and the changes were explained in the announcement. - Using untrusted X11 forwards over SSH (e.g. ssh -X or PuTTY) ssh -X hasn't been supported since X11R7.4 way back in 2008 (see the FAQ for details). As a software engineer I strongly believe in the principle of least astonishment [2]. At least for the vast majority of users. In this case, in my opinion at least, that would mean that changing the behaviour of startxwin should be done in such a way as to provide a seamless way of users to upgrade. Preferably by maintaining compatibility with existing configurations, or by automatic conversion, or, if necessary through a well documented manual transition process. That's what the announcement was for. What I am trying to say is that I don't object to your solutions, but I would really like this to be solved in a way that provides a create user experience. For me that would mean that the first step would be to retract the update (revert back to 1.3.2-1) as to prevent more users from running into problems. I do realize that that would mean forcing people who have already converted to go back. But I assume this is a minority of users. Then I would propose to evaluate what could be done to provide a smooth transition, possibly over a longer time, popping up increasingly annoying warnings about the configuration, for example. I am not going to revert the recent changes, which are important and long overdue. If any has constructive suggestions for incremental improvements thereto, they will be duly considered, but going backwards is not the solution. So I withdraw my previous request that you not post your policy question to the Cygwin main list (since I agree it is a general issue) but instead request that you only discuss the policy and not overlap with the specifics covered in the xinit package threads [..] Thank you, I would like to discussion on the general list to be broader. That won't be necessary. As a rolling distribution without stable releases, these kind of changes in UX happen from time to time. That's what announcements are for. Yaakov -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: run.exe will not work with upgrade from 1.14.4 to 1.16.3
On 5-1-2015 10:48, Yaakov Selkowitz wrote: Just .startxwinrc, and the changes were explained in the announcement. The information is contained within the announcement, but it is a bit difficult to figure out what to do from just the list of changes. A more detailed step-by-step guide, preferably as part of the FAQ would be very much appreciated. ssh -X hasn't been supported since X11R7.4 way back in 2008 (see the FAQ for details). I see, but PuTTY which apparently uses insecure forwards has worked for many years all the way up to 1.3.2-1. That's what the announcement was for. As mentioned above a bit more guidance would be nice. I am not going to revert the recent changes, which are important and long overdue. If any has constructive suggestions for incremental improvements thereto, they will be duly considered, but going backwards is not the solution. OK, I am a bit disappointed, but I do have some suggestions. How would you prefer I post them? In this thread or a new one? All together or one post per suggestion? That won't be necessary. As a rolling distribution without stable releases, these kind of changes in UX happen from time to time. That's what announcements are for. Are you saying it is inappropriate to discuss or that you personally don't see value in this? Laurens -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: run.exe will not work with upgrade from 1.14.4 to 1.16.3
On 2015-01-05 04:03, Laurens Blankers wrote: On 5-1-2015 10:48, Yaakov Selkowitz wrote: Just .startxwinrc, and the changes were explained in the announcement. The information is contained within the announcement, but it is a bit difficult to figure out what to do from just the list of changes. A more detailed step-by-step guide, preferably as part of the FAQ would be very much appreciated. I can't be everyone's personal IT department. I believe the information in the announcement contains sufficient information for users to make the necessary changes, but the most important part would be the new requirements of ~/.startxwinrc. ssh -X hasn't been supported since X11R7.4 way back in 2008 (see the FAQ for details). I see, but PuTTY which apparently uses insecure forwards has worked for many years all the way up to 1.3.2-1. Then please provide complete details in a separate thread. I am not going to revert the recent changes, which are important and long overdue. If any has constructive suggestions for incremental improvements thereto, they will be duly considered, but going backwards is not the solution. OK, I am a bit disappointed, but I do have some suggestions. How would you prefer I post them? In this thread or a new one? All together or one post per suggestion? Please start a new thread. That won't be necessary. As a rolling distribution without stable releases, these kind of changes in UX happen from time to time. That's what announcements are for. Are you saying it is inappropriate to discuss or that you personally don't see value in this? There is simply no point. Yaakov -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: run.exe will not work with upgrade from 1.14.4 to 1.16.3
On 5-1-2015 05:04, Larry Hall (Cygwin-X) wrote: So I'm guessing with your statement above that English isn't your primary language. [..] 1. I am not the maintainer of the xinit package. [..] English is indeed not my first language, but that is no excuse for not carefully reading your replies and not verifying assumptions about you being a maintainer. I did not read your replies carefully enough and did not check my assumptions. Please accept my apologies. [..] 2. Yaakov is a very capable and prolific contributor to the Cygwin project and has been for many years. [..] I do appreciate your (yours, Yaakov's, and others) efforts very much. I tried to express that in the last paragraph of my original mail [1]. Please tell me if this intent did not come across or was drowned somehow, so I can phrase it better next time. [..] You'll notice that sometimes Yaakov is answering the question raised and other times others are doing it. That's standard operating procedure. [..] I did read all the previous questions and answers. I interpreted the focus on having users change their configuration rather than changing the xinit package as a denial of the problem. However, now I see that none of the replies were by the package maintainer. I now realize that you were doing the best you could in helping me and others. [..] When I mentioned above that you or others can help out by pointing out where the solutions proposed fall short [..] As far as I can tell, from the available information, users which meet any of the following criteria will run into trouble: - Custom .startxwinrc or .xinitrc - Using untrusted X11 forwards over SSH (e.g. ssh -X or PuTTY) My assumption is that this covers the vast majority of xinit users. Including these which previously complained about the non-standard way of handling configuration. As a software engineer I strongly believe in the principle of least astonishment [2]. At least for the vast majority of users. In this case, in my opinion at least, that would mean that changing the behaviour of startxwin should be done in such a way as to provide a seamless way of users to upgrade. Preferably by maintaining compatibility with existing configurations, or by automatic conversion, or, if necessary through a well documented manual transition process. What I am trying to say is that I don't object to your solutions, but I would really like this to be solved in a way that provides a create user experience. For me that would mean that the first step would be to retract the update (revert back to 1.3.2-1) as to prevent more users from running into problems. I do realize that that would mean forcing people who have already converted to go back. But I assume this is a minority of users. Then I would propose to evaluate what could be done to provide a smooth transition, possibly over a longer time, popping up increasingly annoying warnings about the configuration, for example. I would like to help with this. I think I can assist in figuring out what kind of configurations are out there, as well as in testing, and in writing documentation. I could even code the solution, but that would probably be more efficient of people with more experience in bash scripting would do that. [..] So I withdraw my previous request that you not post your policy question to the Cygwin main list (since I agree it is a general issue) but instead request that you only discuss the policy and not overlap with the specifics covered in the xinit package threads [..] Thank you, I would like to discussion on the general list to be broader. Because, for me, this issue was highlighted by xinit, but is by no means related to it. I, and I assume many others, rely on Cygwin and also assume, possibly incorrectly, that it will continue to function as expected, after applying (security) updates. An incompatible change in any other package would also be problematic for me. The reason I mentioned xinit explicitly is to provide the reader with a background, and as soft of a 'full disclosure' of my involvement. I will also make it very explicit on the common list that the post is not specific to xinit, but that is merely serves as an example. A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? I really like your signature, do you mind if I borrow/steal it? Laurens [1] https://cygwin.com/ml/cygwin-xfree/2014-12/msg00060.html [2] http://en.wikipedia.org/wiki/Principle_of_least_astonishment -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Can't open display with PuTTY and xinit 1.3.4-1
When using PuTTY with X11 forwarding enabled X clients are no longer able to connect to the X server running locally. When reverting back to 1.3.2-1 the problem goes away. This may be related to the -nolisten tcp which is now the default[1]. If this is indeed the case it would be create of adding the '-listen' flag to startxwin could be added to the FAQ. Or another, more secure, solution would also be appreciated. [1] https://cygwin.com/ml/cygwin-xfree/2014-12/msg00024.html Laurens -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Suggestion for improving xinit 1.3.4
Hi, As requested [1] a separate thread for suggesting improvements to xinit, in order to solve some of the issues people have been having since the release of 1.3.4-1 [2]. 1. Handling of empty .startxwinrc Given the new behaviour of startxwin having an empty is never a correct configuration. It would be really nice if startxwin could check for a zero length .startxwinrc and in that case just start the X server without any programs, as it used to do in 1.3.2-1. This would solve a problem reported several times [3, 4] and also solve the problem of having an icon on the task bar for 'sleep inf' [5]. 2. Adding a hint about 'sleep inf' to the FAQ Not everyone reads the release notes, most people, when running into problems will read the FAQ first. How about adding an entry similar to this one: Q: startxwin exits immediately on start-up without error A: ~/.startxwinrc must be executable and block or else X server will exist, adding a 'sleep inf' to the end of the file should help, also see [2] 3. Adding 'listen' option to the FAQ Consider adding something similar: Q: X server is no longer accepting client connections, how come? A: For security reasons, by default the X server no longer listen for tcp connections, if you really want this add '-listen' to the start-up parameters. Also see [6]. 4. Semantic versioning Signalling major changes in the version number makes it a lot easier to find the problem, at least for me. Semantic versioning [7] suggest does thing. Practically this would have mend calling the latest release 2.0.0-1 rather than 1.3.4-1. No additional effort required, but a clear signal to people to read the release notes. I hope these suggestions don't require too much work. I think they would have a significant positive impact on UX. Laurens [1] https://cygwin.com/ml/cygwin-xfree/2015-01/msg00012.html [2] https://cygwin.com/ml/cygwin-xfree/2014-11/msg00029.html [3] https://cygwin.com/ml/cygwin-xfree/2014-12/msg00012.html [4] https://cygwin.com/ml/cygwin-xfree/2014-12/msg00013.html [5] https://cygwin.com/ml/cygwin-xfree/2014-12/msg00059.html [6] https://cygwin.com/ml/cygwin-xfree/2015-01/msg00013.html [7] http://semver.org/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Can't open display with PuTTY and xinit 1.3.4-1
On 2015-01-05 05:31, Laurens Blankers wrote: When using PuTTY with X11 forwarding enabled X clients are no longer able to connect to the X server running locally. When reverting back to 1.3.2-1 the problem goes away. This may be related to the -nolisten tcp which is now the default[1]. If this is indeed the case it would be create of adding the '-listen' flag to startxwin could be added to the FAQ. Or another, more secure, solution would also be appreciated. Wait, are you talking about a Windows version of PuTTY? Then that makes sense, as it would be unable of using the *NIX socket typically used by local X clients, and I am indeed able to duplicate that behaviour. I can't think of an alternative to -listen if you wish to use a Windows PuTTY (or, for that matter, any MinGW-compiled X client) with Cygwin/X. This will be added to the FAQ in due course. However, a Cygwin PuTTY does not have that limitation, and X11 forwarding works just fine as is. (If there is interest, I can easily add this to the distribution.) Similarly, the Cygwin (open)ssh obviously has no problems with X11 forwarding either. BTW, reverting this behaviour isn't an option either, as it will actually become the upstream default in the next major release of the X server. HTH, Yaakov -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: run.exe will not work with upgrade from 1.14.4 to 1.16.3
On 01/05/2015 04:06 AM, Laurens Blankers wrote: snip Since I believe the rest of what you wrote above has been covered in one form or another since my last reply, I won't bore anyone with my responses. This leaves just one very critical piece of business which absolutely must be addressed: A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? I really like your signature, do you mind if I borrow/steal it? Of course! I actually borrowed it from someone else a few lifetimes ago so it would hardly be sporting of me to deny you equal rights. :-) -- Larry _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Suggestion for improving xinit 1.3.4
On 2015-01-05 05:46, Laurens Blankers wrote: As requested [1] a separate thread for suggesting improvements to xinit, in order to solve some of the issues people have been having since the release of 1.3.4-1 [2]. 1. Handling of empty .startxwinrc Given the new behaviour of startxwin having an empty is never a correct configuration. It would be really nice if startxwin could check for a zero length .startxwinrc and in that case just start the X server without any programs, as it used to do in 1.3.2-1. This would solve a problem reported several times [3, 4] and also solve the problem of having an icon on the task bar for 'sleep inf' [5]. And what if it's not zero-length but still blank? 2. Adding a hint about 'sleep inf' to the FAQ Not everyone reads the release notes, most people, when running into problems will read the FAQ first. How about adding an entry similar to this one: Q: startxwin exits immediately on start-up without error A: ~/.startxwinrc must be executable and block or else X server will exist, adding a 'sleep inf' to the end of the file should help, also see [2] Yes, something along these lines should be added to the FAQ soon. 3. Adding 'listen' option to the FAQ See my response to your PuTTY thread. 4. Semantic versioning Signalling major changes in the version number makes it a lot easier to find the problem, at least for me. Semantic versioning [7] suggest does thing. Practically this would have mend calling the latest release 2.0.0-1 rather than 1.3.4-1. No additional effort required, but a clear signal to people to read the release notes. xinit -- the startx and xinit parts -- is an upstream X.Org package, and they determine the package version. The startxwin components are Cygwin-specific additions to the package, as they have been since we first released modular X11R7.4. Therefore, changing the version in this way isn't a viable option here. However, from personal experience, I disagree that a different version number would have made a bit of difference. Either people will read the announcements -- and the subject of mine should have indicated that this wasn't a routing update -- or they won't. -- Yaakov -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Suggestion for improving xinit 1.3.4
On 2015-01-05 11:43, Yaakov Selkowitz wrote: On 2015-01-05 05:46, Laurens Blankers wrote: As requested [1] a separate thread for suggesting improvements to xinit, in order to solve some of the issues people have been having since the release of 1.3.4-1 [2]. 1. Handling of empty .startxwinrc Given the new behaviour of startxwin having an empty is never a correct configuration. It would be really nice if startxwin could check for a zero length .startxwinrc and in that case just start the X server without any programs, as it used to do in 1.3.2-1. This would solve a problem reported several times [3, 4] and also solve the problem of having an icon on the task bar for 'sleep inf' [5]. And what if it's not zero-length but still blank? I could have startxwin check if ~/.startxwinrc is executable, and skip if it not, which might also cover many of these empty .startxwinrc's. OTOH all that might accomplish is trade the why won't it start for why doesn't it respect my config. :-) -- Yaakov -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
