On Thu, 2002-05-09 at 19:25, Tom Lane wrote: > mlw <[EMAIL PROTECTED]> writes: > > I have used the cygwin version too. It is a waste of time. No Windows user will > > ever accept it. No windows-only user is going to use the cygwin tools. > > With decent packaging, no windows-only user would even know we have > cygwin in there. The above argument is just plain irrelevant. The real > point is that we need a nice clean friendly GUI for both installation > and administration --- and AFAICS that will take about the same amount of > work to write whether the server requires cygwin internally or not.
<evil grin> We can go the Oracle way and write a 200MB cross-platform java installer requiring and exact version of java runtime </evil grin> > Rather than expending largely-pointless work on internal rewrites of > the server, people who care about this issue ought to be thinking about > the GUI problems. pgAccess is quite nice (Disclaimer: I'm not a windows weenie, I run it inside vmware/win98 IE browser test environment on my Linux workstation ;). Why not just bundle what we've got ? > > From a production stand point, would anyone reading this trust their > > data to PostgreSQL running on cygwin? > > I wouldn't trust my data to *any* database running on a Microsoft OS. > Period. Do we support Xenix and SCO ? > The above argument thus doesn't impress me at all, especially > when it's being made without offering a shred of evidence that cygwin > contributes any major degree of instability. >From the comments here it seems to be either cygwin or more likely cygipc > I am especially unhappy about the prospect of major code revisions > and development time spent on chasing this rather than improving our > performance and stability on Unix-type OSes. I agree with the comment > someone else made: that's just playing Microsoft's game. Not! I think that this thread is mostly about coordinating code and interface cleanups that are likely beneficial for both *NIX and non-*NIX platforms mainly * cleaner support for semaphores * separating shared and per-process data * process creation * (file operations) * (init and service scripts) if done properly none of these will degrade code quality nor performance. Also, having a clean interface for those will not only enable any interested party to make windows/BeOS/OSX/QNX binaries with less effort, it will most likely make it easier make use of advances in *NIX world like AIO, multiprocessor systems, NUMA and distributed systems, and just make things more robust and reliable by making code inspection easier. --------------- Hannu ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
