On Thu, 2002-05-09 at 19:25, Tom Lane wrote:
> mlw <markw@mohawksoft.com> 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)*
(initand 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
