[PATCH 00/39] Windows port, base and archival/

[Rob Landley]

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