From: | Jean-Michel POURE <jm(dot)poure(at)freesurf(dot)fr> |
---|---|
To: | mlw <markw(at)mohawksoft(dot)com> |
Cc: | Robert <robert(at)robert(dot)cz>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pgAdmin2 to be included in Dev-C++ |
Date: | 2002-05-10 13:26:02 |
Message-ID: | 200205101526.02613.jm.poure@freesurf.fr |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Dear Mark,
Agreed except for paths (see below). But now that we agree, why not move to
Windows in three steps:
1) Release a minimal Cygwin + PostgreSQL installer,
2) Have 100.000 downloads or more Windows developpers,
3) Work as a team on a Windows port.
By the way : Cygwin accepts both Windows AND Unix paths depending on
installation options. Cygwin is able to understand C:\program
files\postgresql\var\lib\pgsql, /cygdrive/../var/lib/pgsql or simply
/var/lib/pgsql.
Cheers,
Jean-Michel
> Here are the problems with cygwin:
> (1) GNU license issues.
> (2) Does not work well with anti-virus software
> (3) Since OS level copy-on-write is negated, process creation is much
> slower. (4) Since OS level copy-on-write is negated, memory that otherwise
> would not be allocated to the process is forced to be allocated when the
> parent process data is copied.
> As a product manager, I would not commit to using a cygwin application in
> production. Do you know of any long-uptime systems using cygwin? PostgreSQL
> would need to run for months. I would view it as a risk.
> Lastly, a Windows program is expected to be a Windows program. Native paths
> need to be used, like C:\My Database, D:\My Postgres, or something like
> that. Native tools must be used to manage it.
From | Date | Subject | |
---|---|---|---|
Next Message | mlw | 2002-05-10 13:33:37 | Re: pgAdmin2 to be included in Dev-C++ |
Previous Message | Justin Clift | 2002-05-10 13:20:43 | Re: pgAdmin2 to be included in Dev-C++ |