On Friday 21 May 2010 03:02:13 Mike Frysinger wrote: > so really you have no solution other than "Windows isnt supported". if you > arent interested in working on something, then stop wasting people's time. > -mike
1) Thats a fairly context-free message. Were you replying to me, or were you replying to Nguyen? Were you replying to a specific message, or is this a general comment? I'll assume it was addressed to me. 2) Cygwin works just fine last I checked, how is this not a solution? 3) I _think_ what you're saying is if I'm not interested in writing or supporting Windows code I should stop working on BusyBox. Despite working on BusyBox never previously having required knowledge of Windows development. 4) Let's summarize the thread, shell we? Nguyen's objection was that Cygwin's glue layer to make Windows look like Posix is too heavyweight. His solution wasn't to slim down cygwin, but instead to reinvent this glue layer as part of BusyBox. To show us how simple and lightweight this new glue layer could be, he proposed starting with a 39-patch series that was almost entirely _setup_ for future changes, and didn't actually add support for a significant number of applets. So from the perspective of not having solved the problem, he just knew it was a small problem that would stay small and manageable as he tried to tackle more of it. I don't believe the "too big" problem is entirely cygnus, I believe that the fundamental problem is that Win32 and Posix are very dissimilar and making one look like the other is a big job. (Wine, going the other way, isn't a trivial project either. They spent something like eight years in alpha test.) There is a case to be made that cygwin is bigger than it needs to be becuase it's full of gnu bloatware. So of course your suggestion was to suck in gnu code to fashion a busybox-to-windows glue layer out of. And you see no problem with this. There's also the "oh, but we'll only solve _part_ of this problem and leave the rest unsolved, and be small by doing a half-assed job which nobody will ever try to use as precedent to push more of the same into the project in future". The phrase Peter Salus used for this was "the camel's nose under the tent flap". It tends to be followed by the rest of the camel. If you cross a boundary, where is the next boundary? Nobody seemed to have a clear answer to that one. If you want to slim down cygwin, do it. If you want to extend mingw, do that. If you want to split the difference and try to write a thin glue layer on top of mingw that's good enough to build things like busybox but smaller than cygwin, go for it. My point is, this is not busybox's job. Alan Cox once told me "a maintainer's job is to say no".* You're suggesting that everyone who ever objects that something is outside the scope of the project is merely being obstructionist. This implies it's a _good_ thing that Mozilla was made skinnable in XML long before the basic rendering functionality was finished, and the 10 years of thrashing and 2 forks (Galleon and Firefox) needed to produce something usable were totally unrelated to that. I side with Alan on this one. Rob * Of course Denys is BusyBox maintainer. Alan wasn't Linux maintainer either, and was semi-retired from Linux development when he said this. The point is to undestand the importance of architectural decisions for open souruce projects. -- Latency is more important than throughput. It's that simple. - Linus Torvalds _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
