Обсуждение: Microsoft releses Services for Unix

Hello,

Microsoft just decided to make Services for Unix a free download.  The
package includes a lot of features to make a win32 computer more usable
in a mixed network.   It also includes posix libraries, shells, even gcc
in a unix-ish build environment similar to cygwin (they call it
'Interix').

Perhaps with this new development it might be worthwhile investigating
getting postgres compiled using this build environment.  This might be a
way to shortcut the win32 porting effort and keep the win32 specific
code in postgres down to an absolute minimum.

Merlin

> Perhaps with this new development it might be worthwhile investigating
> getting postgres compiled using this build environment.  This might be
a
> way to shortcut the win32 porting effort and keep the win32 specific
> code in postgres down to an absolute minimum.

Included with MS SFU is:
Full sys V IPC
Full posix signals
posix threads (as of 3.5)
gcc 3.3
x11

Apparently most of the SFU as based on a fork of OpenBSD.  Unlike Cygwin
which is emulated, SFU sys calls interact directly with the windows HAL,
so it should be robust and faster.

Maybe it would be a more worthwhile error getting postgres to compile
under this environment instead of re-implementing unix system calls.

Thoughts?
Merlin

Windows users will always prefer a Windows solution to a Unix solution running on SFU... I'd say sticking with the
originalgoal of making a native Win32 version would be preferable. 



-----Original Message-----
From: Merlin Moncure [mailto:merlin.moncure@rcsonline.com]
Sent: Miércoles, 14 de Enero de 2004 03:34 p.m.
To: pgsql-hackers-win32
Subject: Re: [pgsql-hackers-win32] Microsoft releses Services for Unix

> Perhaps with this new development it might be worthwhile investigating
> getting postgres compiled using this build environment.  This might be
a
> way to shortcut the win32 porting effort and keep the win32 specific
> code in postgres down to an absolute minimum.

Included with MS SFU is:
Full sys V IPC
Full posix signals
posix threads (as of 3.5)
gcc 3.3
x11

Apparently most of the SFU as based on a fork of OpenBSD.  Unlike Cygwin which is emulated, SFU sys calls interact
directlywith the windows HAL, so it should be robust and faster. 

Maybe it would be a more worthwhile error getting postgres to compile under this environment instead of re-implementing
unixsystem calls. 

Thoughts?
Merlin





---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

> -----Original Message-----
> From: Steve Tibbett [mailto:stibbett@zim.biz]
> Sent: 14 January 2004 20:42
> To: Merlin Moncure; pgsql-hackers-win32
> Subject: Re: [pgsql-hackers-win32] Microsoft releses Services for Unix
>
> Windows users will always prefer a Windows solution to a Unix
> solution running on SFU... I'd say sticking with the original
> goal of making a native Win32 version would be preferable.

Plus I'll bet we couldn't distribute the required components ourselves
and would thus require the user to download interix first.

Regards Dave.

Dave Page wrote:
> Steve Tibbett  wrote:
> > Windows users will always prefer a Windows solution to a Unix
> > solution running on SFU... I'd say sticking with the original
> > goal of making a native Win32 version would be preferable.
>
> Plus I'll bet we couldn't distribute the required components ourselves
> and would thus require the user to download interix first.

Yes, but consider this:
1. from a windows developer's point of view, requiring Interix is no
better or worse than requiring cygwin or mingw, except for maybe the
size of the download/install.

2. Interix will be faster than any emulated I/O.  sync() right now is
very slow because there is no corresponding win32 API call.  Interix
implements this as an optimized kernel mode driver.  That right there is
reason enough for me.

3. Postgres no longer contains tons of extra code specifically to
support windows.

4. 'Native' is a funny term.  Interix runs at the same operations level
as the win32 API (not above it, as cygwin, or application level
emulation code).  To a certain way of thinking, Interix applications are
more native than win32 API code written to achieve the same purpose.

The soon to be released version 3.5 has greatly beefed up performance
and support for threads.  Unless I completely misunderstand things,
getting a native win32 port for postgresql off the ground will boil down
to downloading interix and hacking out a configure script...is this
correct?

Merlin

> > > Windows userswill always prefer a Windows solution to a Unix
> > > solution running on SFU... I'd say sticking with the
> original goal
> > > of making a native Win32 version would be preferable.
> >
> > Plus I'll bet we couldn't distribute the required
> components ourselves
> > and would thus require the user to download interix first.
>
> Yes, but consider this:
> 1. from a windows developer's point of view, requiring
> Interix is no better or worse than requiring cygwin or mingw,
> except for maybe the size of the download/install.

Taking off the developer hat and putting on the sysadmin hat, from what
I've seen on earlier versions of SFU, I would *much much* prefer SFU
over Cygwin.
a) It's smaller (very much so)
b) It's implemented at a lower layer. It's not on top of Win32, it's
beside it.
c) It's MS. This means it's included in MS support agreements etc.


> 4. 'Native' is a funny term.  Interix runs at the same
> operations level as the win32 API (not above it, as cygwin,
> or application level emulation code).  To a certain way of
> thinking, Interix applications are more native than win32 API
> code written to achieve the same purpose.

To be strict, it'd probably not be native win32, but native NT. In
reality, people wouldn't care that much - it's native windows.


> The soon to be released version 3.5 has greatly beefed up
> performance and support for threads.  Unless I completely
> misunderstand things, getting a native win32 port for
> postgresql off the ground will boil down to downloading
> interix and hacking out a configure script...is this correct?
Maybe not quite that easy, but it should be a lot less work from what I
read.


One has to read the license agreements *really* careful, though. Also
any deals on redistribution (can we package a merge module for it along
with the server in a binary distribution, or does i thave to be DLed
from MS for example).

I don't think most Windows admin people will have much problem with
installing a free piece of MS software (after all, we all have to update
our internet explorers etc every other day). But it comes down to what
the actual license will be (can't seem to find it for the new release,
just the announcements to the press) and how much work is still needed
for the port.

Until we know the license, we should probably stick to the current
plans. (Heck, if we get that one running we can even benchmark them
against each other and see if there's a noticeable difference. And if
there is no difference in performance etc, then yes, go with the one
that doesn't require SFU)


//Magnus

A "Native" Windows application is one that integrates well with the rest of the OS.. meaning it logs to the event log,
runsas a service, supports performance monitor counters, responds to system shutdown and power management events, etc..
tryingto support this stuff while running in Interix might well be impossible (you can't make Win32 calls from outside
theWin32 subsystem can you?) 

Wasn't the goal to get Postgres to work without Cygwin?

 - Steve

-----Original Message-----
From: Merlin Moncure [mailto:merlin.moncure@rcsonline.com]
Sent: Miércoles, 14 de Enero de 2004 04:18 p.m.
To: Dave Page
Cc: pgsql-hackers-win32
Subject: Re: [pgsql-hackers-win32] Microsoft releses Services for Unix

Dave Page wrote:
> Steve Tibbett  wrote:
> > Windows users will always prefer a Windows solution to a Unix
> > solution running on SFU... I'd say sticking with the original goal
> > of making a native Win32 version would be preferable.
>
> Plus I'll bet we couldn't distribute the required components ourselves
> and would thus require the user to download interix first.

Yes, but consider this:
1. from a windows developer's point of view, requiring Interix is no better or worse than requiring cygwin or mingw,
exceptfor maybe the size of the download/install. 

2. Interix will be faster than any emulated I/O.  sync() right now is very slow because there is no corresponding win32
APIcall.  Interix implements this as an optimized kernel mode driver.  That right there is reason enough for me.   

3. Postgres no longer contains tons of extra code specifically to support windows.

4. 'Native' is a funny term.  Interix runs at the same operations level as the win32 API (not above it, as cygwin, or
applicationlevel emulation code).  To a certain way of thinking, Interix applications are more native than win32 API
codewritten to achieve the same purpose. 

The soon to be released version 3.5 has greatly beefed up performance and support for threads.  Unless I completely
misunderstandthings, getting a native win32 port for postgresql off the ground will boil down to downloading interix
andhacking out a configure script...is this correct? 

Merlin

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
      subscribe-nomail command to majordomo@postgresql.org so that your
      message can get through to the mailing list cleanly

> A "Native" Windows application is one that integrates well
> with the rest of the OS.. meaning it logs to the event log,
> runs as a service, supports performance monitor counters,
> responds to system shutdown and power management events,
> etc.. trying to support this stuff while running in Interix
> might well be impossible (you can't make Win32 calls from
> outside the Win32 subsystem can you?)

Hmm. Those are very good points :-)
Phase one is just get up and running, but yes, in the future we'd want
to support many of those. At least be possible to do so.

Does anybody know if a SFU program runs "isolated" under Interix or if
it can run in "both subsystems"? Or does SFU perhaps map services like
syslog over to eventlog etc? (Haven't used SFU for those things before,
just for NFS)

//mha

Steve Tibbett:
> A "Native" Windows application is one that integrates well with the
rest
> of the OS.. meaning it logs to the event log, runs as a service,
supports

My big issues with pg/cygwin are that it's slow and tends to crash a
lot.  Also, the ipc runs as a separate service which also crashes and
does other weird things.  Pg/sfu would not have these problems.

Also, logging/services, etc. are the things that are really different in
windows and could be easily tailored to that platform, as opposed to
writing a signal emulation layer.

> performance monitor counters, responds to system shutdown and power
> management events, etc.. trying to support this stuff while running in
> Interix might well be impossible (you can't make Win32 calls from
outside
> the Win32 subsystem can you?)

Why can't you?  Interix is just another API you can call (a 3rd, on top
of the existing posix implementation and win32).  You can already mix
posix and win32, for example.

Merlin

> -----Original Message-----
> From: Merlin Moncure [mailto:merlin.moncure@rcsonline.com]
> Sent: 14 January 2004 21:18
> To: Dave Page
> Cc: pgsql-hackers-win32
> Subject: RE: [pgsql-hackers-win32] Microsoft releses Services for Unix
>
> Dave Page wrote:
> > Steve Tibbett  wrote:
> > > Windows users will always prefer a Windows solution to a Unix
> > > solution running on SFU... I'd say sticking with the
> original goal
> > > of making a native Win32 version would be preferable.
> >
> > Plus I'll bet we couldn't distribute the required
> components ourselves
> > and would thus require the user to download interix first.
>
> Yes, but consider this:
> 1. from a windows developer's point of view, requiring
> Interix is no better or worse than requiring cygwin or mingw,
> except for maybe the size of the download/install.

I don't expect 99% of PostgreSQL/Win32 users to be developers. I hope we
see a myriad of apps built around a bundled PostgreSQL server, as well
as more advanced users looking to replace Access etc.

> 2. Interix will be faster than any emulated I/O.  sync()
> right now is very slow because there is no corresponding
> win32 API call.  Interix implements this as an optimized
> kernel mode driver.  That right there is reason enough for me.
>
> 3. Postgres no longer contains tons of extra code
> specifically to support windows.

2 definate plus points.

> 4. 'Native' is a funny term.  Interix runs at the same
> operations level as the win32 API (not above it, as cygwin,
> or application level emulation code).  To a certain way of
> thinking, Interix applications are more native than win32 API
> code written to achieve the same purpose.

Maybe.

> The soon to be released version 3.5 has greatly beefed up
> performance and support for threads.  Unless I completely
> misunderstand things, getting a native win32 port for
> postgresql off the ground will boil down to downloading
> interix and hacking out a configure script...is this correct?

Maybe. I think I have 3.5 at the office (we get most MS CDs a little
early). If I get time I'll look tomorrow.

What would scare me more is Microsoft changing the licencing terms in
the future. They already added anti open source clauses to the licence
of one of their products (iirc it was the Mobile Information Server
SDK).

Regards, Dave.

> Dave Page wrote:
> I don't expect 99% of PostgreSQL/Win32 users to be developers. I hope
we
> see a myriad of apps built around a bundled PostgreSQL server, as well
> as more advanced users looking to replace Access etc.

Actually, that is a very good point.  It would put my mind at ease wrt
to SFU if the provided a lightweight runtime to install instead of being
forced to do the whole sdk.  Also, sfu does not run on xp home as well
as entire 9x series.

It would be hard to suggest sfu unless there was a reasonable approach
to making a binary installer.

> What would scare me more is Microsoft changing the licencing terms in
> the future. They already added anti open source clauses to the licence
> of one of their products (iirc it was the Mobile Information Server
> SDK).

That would be pretty low, even for Microsoft :) sfu is essentially an
OpenBSD distro plus a bunch of kernel drivers to handle the sys calls.
There is a lot of speculation on Slashdot about why MS decided to give
this away.  My own personal feeling is they are trying to stamp out the
'except for application x' syndrome.  (Linux penetrates IT shops because
they need it to run that one critical app that hasn't been ported to
windows.  Windows IT admins then get exposure to Linux and use it to
save 600$ in the future.)

The real spoiler though, is performance, MS will be able to write a high
performance POSIX layer, much faster than any community written project.
(I have no idea how fast sfu does run, so time will tell).

Merlin

> Microsoft just decided to make Services for Unix a free download.

Anyway, I'm coming in to this discussion late, but my 2c.

I see marginal benefit in using SFU, for considerable disadvantage.

* Users already have a postgres solution for Win32. It is called Cygwin w/
cygipc. Sure, it is not the most stable solution, but, IMHO, that's not what
prevents people from using it; it is the need to install yet-another bit of
software to support Postgres. If we want to take the fight to MySQL, again
IMNSHO, this is not the way to proceeed.

* We are close to a Win32 port already. When the last patch is applied,
there are only a few minor things to resolve (some "hard-coded" directory
issues, whitespaces in directory names), and two larger ones... namely sync
+ signals. We've believe we are onto a workable solution to signals, and I
personally think the sync issue isn't a big deal.

* I don't buy the argument that moving to SFU will remove a lot of specific
Win32 code. On what evidence is this based on? [personally, I think it'd
only get worse, again, based on little evidence]. Seems to me the bulk of
the Win32 specific code lies with fork/exec, which (unless I'm terribly
mistaken) won't be alleviated by SFU.

I too would much prefer SFU over cygipc, but, frankly, I'd much prefer this
port to go completely without either of them...

At this point, I can't see that this is anything other than a distraction.
Perhaps in the future, but well, I can't see how we'd justify it short of
being unable to suitably "fake" signals (unlikely), or being able to prove
(and that is prove, not assume) that sync performance would greatly improve
under SFU.

Cheers,
Claudio
---
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see
<a
href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em
ailpolicy.html</a>

Claudio Natoli <claudio.natoli@memetrics.com> writes:
> * Users already have a postgres solution for Win32. It is called Cygwin w/
> cygipc. Sure, it is not the most stable solution, but, IMHO, that's not what
> prevents people from using it; it is the need to install yet-another bit of
> software to support Postgres.

Well, the $64 questions that have not been answered are what are the
license terms and redistribution terms for SFU?  If we can bundle the
needed parts of SFU into a binary distribution of Postgres, then there
is no need for users to be aware it is in there.  If we can't, then
I agree that a port based on it would be about as hard to sell as the
Cygwin port.  (Yeah, maybe it'd be more stable and faster, but it'd not
be perceived as a native port.)

Given the previous comments about Microsoft's goals in giving this away,
one would think they'd allow it to be bundled in distributions of free
software.  But who knows ...

> * I don't buy the argument that moving to SFU will remove a lot of specific
> Win32 code. On what evidence is this based on? [personally, I think it'd
> only get worse, again, based on little evidence]. Seems to me the bulk of
> the Win32 specific code lies with fork/exec, which (unless I'm terribly
> mistaken) won't be alleviated by SFU.

If SFU doesn't provide a reasonable fork() emulation then it's no help,
agreed.  But again, from what I understand of Microsoft's goals, I'd
think they'd have to provide a good fork().  I think Postgres is a
perfect poster child for the sort of app they want to make easy to port
to Windows.

            regards, tom lane

> Well, the $64 questions that have not been answered are what are the
license terms and redistribution terms for SFU?

Don't know yet. The current coverage says that it is being released for free
this week, but I can't find anything with the exact license terms (only for
the previous [non-free] versions)... anyone?


> Given the previous comments about Microsoft's goals in giving this away,
> one would think they'd allow it to be bundled in distributions of free
> software.  But who knows ...

True, but I think the real, unanswerable question is "But who knows FOR HOW
LONG?".


> If SFU doesn't provide a reasonable fork() emulation then it's no help,
agreed.

It does (and clearly can, as the NT kernel architecture certainly allows
this; just the Win32 API provides no mechanism for doing so), but it ain't
perfect. Well, it wasn't when I first used SFU which was some time ago.
Anyone here have recent experience with this?

In any case, my vote continues to be for steering clear of it, but I've
nothing new to add to the discussion.

Cheers,
Claudio

---
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see
<a
href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em
ailpolicy.html</a>

I didn't see the package available for download earlier, but it appears
to be posted now.
http://www.microsoft.com/downloads/details.aspx?FamilyID=019139c0-16ff-4
de5-bba3-7e2515f0f7a9&DisplayLang=en

Here's a short summary of some of the capabilities of SFU (Slashdot
poster):


We've been using SFU 3.0 and its predecessor for 5 years now to provide
our Database Engine and Tools on Windows Boxes as well as our usual
Solaris, AIX, Linux, Unixware and SGI. I woudl like to think that by now
I am one of the more experienced Interix developers kicking round. I
have to say, It's really very good and keeps getting better. MS are
moving to being Unix by stealth, SFU is a unix on the NT Microkernal and
it doesnt suffer from Win32 issues. Fork works, You can delete a file
thats in use (yes inodes work !!), create a new one with the same name
and open that in a different process. I've seen Interix 2.0 evolve info
SFU 3.0 and 3.5 and I've had MS fix bugs in the allocator part of MMAP
within days and release a private patch. Somehow I think there is a
little group of diehard Unix lovers in MS working to turn everything on
its head the same way Apple got OSX. Anyway waffle over - Try it as a
build environment it's geat. What I want to see is Wine on SFU - then
All windows apps work over X - whoopee.

Jim

-----Original Message-----
From: pgsql-hackers-win32-owner@postgresql.org
[mailto:pgsql-hackers-win32-owner@postgresql.org] On Behalf Of Merlin
Moncure
Sent: Wednesday, January 14, 2004 1:12 PM
To: pgsql-hackers-win32
Subject: [pgsql-hackers-win32] Microsoft releses Services for Unix

Hello,

Microsoft just decided to make Services for Unix a free download.  The
package includes a lot of features to make a win32 computer more usable
in a mixed network.   It also includes posix libraries, shells, even gcc
in a unix-ish build environment similar to cygwin (they call it
'Interix').

Perhaps with this new development it might be worthwhile investigating
getting postgres compiled using this build environment.  This might be a
way to shortcut the win32 porting effort and keep the win32 specific
code in postgres down to an absolute minimum.

Merlin

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

               http://archives.postgresql.org

> Well, the $64 questions that have not been answered are what
> are the license terms and redistribution terms for SFU?  If
> we can bundle the needed parts of SFU into a binary
> distribution of Postgres, then there is no need for users to
> be aware it is in there.  If we can't, then I agree that a
> port based on it would be about as hard to sell as the Cygwin
> port.  (Yeah, maybe it'd be more stable and faster, but it'd
> not be perceived as a native port.)

I see the following in the MS newsgroups about the licensing:


1) sfu3.5 is still a licensed product, even though it is free.
   The license details are on the distribution ( doc/eula.txt).
   As far as I know, MS is not allowing re-distribution of SFU
components.

   There is an ISV program for those that want to embed the Interix
subsytem
   and/or utils into their product.  You'll need to contact  Interop
Systems about that.



This rules out integrated installer, if you can't redist..

The referenced EULA in the Beta is unfortunatly for the beta version
only (it's filled with info that the berta can only be used for testing
and demonstrati9on, will expire etc)
I'll see if I can get hold of the final EULA from our MS reps, but I
wouldn't be surprised if I can't...

//Magnus

Claudio Natoli wrote:
> * Users already have a postgres solution for Win32. It is called
Cygwin w/
> cygipc. Sure, it is not the most stable solution, but, IMHO, that's
not
> what
> prevents people from using it; it is the need to install yet-another
bit
> of
> software to support Postgres. If we want to take the fight to MySQL,
again
> IMNSHO, this is not the way to proceeed.

I don't use it because I don't feel it is stable and the write
performance is not very good.  Also, the ipc-daemon sometimes crashes
which is a big PITA.  Also, some months back Justin Clift made a proof
of concept installer for cygwin based version.

It's unclear if such an installer could be made for sfu.

> * We are close to a Win32 port already. When the last patch is
applied,
> there are only a few minor things to resolve (some "hard-coded"
directory
> issues, whitespaces in directory names), and two larger ones... namely
> sync
> + signals. We've believe we are onto a workable solution to signals,
and I
> personally think the sync issue isn't a big deal.

I agree with you very much on this point.  At the very least, we should
run both version side by side and make an objective comparison.

> At this point, I can't see that this is anything other than a
distraction.
> Perhaps in the future, but well, I can't see how we'd justify it short
of
> being unable to suitably "fake" signals (unlikely), or being able to
prove
> (and that is prove, not assume) that sync performance would greatly
> improve
> under SFU.

Admittedly I didn't give full consideration to the installation issues
of the SFU version.  The performance of course is a big question mark;
it could be much better or much worse than a hand coded port.  Plus, the
win32 is so close to completion I can almost taste it... :)

Also, even if sync() and other I/O calls are a problem, the win32 API
has a lot of I/O optimization potential so that is not necessarily a
long term problem.

Merlin

Steve Tibbett wrote:
> Interix might well be impossible (you can't make Win32 calls from
outside
> the Win32 subsystem can you?)

The answer to that question is complex...
You can link visual studio compiled libraries (including static dlls) to
interix compiled app.
You can exec() win32 compiled apps
You can make calls to ntdll.dll (but not kernel32.dll)
You can make calls to any other dll, but those dlls should not call
kernel32.dll (not sure on this)...may have to block threads/sigs in this
case.
You will not be able to #include windows.h compiler will bork...
From the 'unix' shell, you can run windows apps with convention similar
to

posixrun /[...]/word.exe (or something like this)

Dave Page wrote:
>
> Plus I'll bet we couldn't distribute the required components ourselves
> and would thus require the user to download interix first.

http://www.microsoft.com/windows/sfu/default.asp

In order to download SFU you have to have a .NET Passport. Since
I don't have one, and have little interest in obtaining one, I
can't tell what the final licence is. Maybe somebody with a
Passport can get the final release and tell us?

I expect that seeing the license will end the debate.

Jochem

--
I don't get it
immigrants don't work
and steal our jobs
     - Loesje

Hi everyone,

I downloaded Microsoft Windows Services for UNIX 3.5 from the site below
(having a NET Passport) and have attached the eula.txt that came with the
download.

The download itself is 223 mb and the unzipped files about 450 mb.  I did
not install the package so I do not know how big it would be fully
installed.

HTH,
George


----- Original Message -----
From: "Jochem van Dieten" <jochemd@oli.tudelft.nl>
To: "Dave Page" <dpage@vale-housing.co.uk>
Cc: "pgsql-hackers-win32" <pgsql-hackers-win32@postgresql.org>
Sent: Thursday, January 15, 2004 1:12 PM
Subject: Re: [pgsql-hackers-win32] Microsoft releses Services for Unix


> Dave Page wrote:
> >
> > Plus I'll bet we couldn't distribute the required components ourselves
> > and would thus require the user to download interix first.
>
> http://www.microsoft.com/windows/sfu/default.asp
>
> In order to download SFU you have to have a .NET Passport. Since
> I don't have one, and have little interest in obtaining one, I
> can't tell what the final licence is. Maybe somebody with a
> Passport can get the final release and tell us?
>
> I expect that seeing the license will end the debate.
>
> Jochem
>
> --
> I don't get it
> immigrants don't work
> and steal our jobs
>      - Loesje
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
>       joining column's datatypes do not match
>

I forgot to add, the date on the eula.txt file when unzipped is 08/11/2003.

George

----- Original Message -----
From: "George Weaver" <gweaver@shaw.ca>
To: "Jochem van Dieten" <jochemd@oli.tudelft.nl>; "Dave Page"
<dpage@vale-housing.co.uk>
Cc: "pgsql-hackers-win32" <pgsql-hackers-win32@postgresql.org>
Sent: Thursday, January 15, 2004 3:26 PM
Subject: Re: [pgsql-hackers-win32] Microsoft releses Services for Unix


> Hi everyone,
>
> I downloaded Microsoft Windows Services for UNIX 3.5 from the site below
> (having a NET Passport) and have attached the eula.txt that came with the
> download.
>
> The download itself is 223 mb and the unzipped files about 450 mb.  I did
> not install the package so I do not know how big it would be fully
> installed.
>
> HTH,
> George
>
>
> ----- Original Message -----
> From: "Jochem van Dieten" <jochemd@oli.tudelft.nl>
> To: "Dave Page" <dpage@vale-housing.co.uk>
> Cc: "pgsql-hackers-win32" <pgsql-hackers-win32@postgresql.org>
> Sent: Thursday, January 15, 2004 1:12 PM
> Subject: Re: [pgsql-hackers-win32] Microsoft releses Services for Unix
>
>
> > Dave Page wrote:
> > >
> > > Plus I'll bet we couldn't distribute the required components ourselves
> > > and would thus require the user to download interix first.
> >
> > http://www.microsoft.com/windows/sfu/default.asp
> >
> > In order to download SFU you have to have a .NET Passport. Since
> > I don't have one, and have little interest in obtaining one, I
> > can't tell what the final licence is. Maybe somebody with a
> > Passport can get the final release and tell us?
> >
> > I expect that seeing the license will end the debate.
> >
> > Jochem
> >
> > --
> > I don't get it
> > immigrants don't work
> > and steal our jobs
> >      - Loesje
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 9: the planner will ignore your desire to choose an index scan if
your
> >       joining column's datatypes do not match
> >
>

George Weaver <gweaver@shaw.ca> writes:
> I forgot to add, the date on the eula.txt file when unzipped is 08/11/2003.

Yeah, I was thinking while I read it that this license seems to have no
clue that it's for software that's being given away free :-(.  Obviously
they have not changed it since SFU was a normal product.

Until it occurs to Microsoft to adjust their license terms, the idea of
using SFU as part of the Postgres port seems to be right out.  Oh well.

            regards, tom lane

> Claudio Natoli wrote:
> > * Users already have a postgres solution for Win32. It is called Cygwin
> > w/ > cygipc. Sure, it is not the most stable solution, but, IMHO,
> > that's not what prevents people from using it; it is the need to
> > install yet-another bit of software to support Postgres. If we want
> > to take the fight to MySQL, again IMNSHO, this is not the way to
> > proceeed.
>
> I don't use it because I don't feel it is stable and the write
> performance is not very good.  Also, the ipc-daemon sometimes crashes
> which is a big PITA.

Exactly why we don't (can't!) use it in production. I was referring more to
the person we want to win over to Postgresql; the person who'll download the
Postgres Win32 binaries, and make a decision within 5 minutes as to whether
to keep playing with it, or whether to ditch it forever.

As Tom has said, if we can redistribute the components "invisibly" (which
the existing license appears to be completely silent on), great, and it is
something we might want to look at, IMHO, at a later date. Otherwise, forget
it.

Aside: Looking *much* further ahead, with all Microsoft OS moving to the NT
subkernel, and this latest announcement that SFU is now available at no
cost, I think it is pretty clear that, sooner or later, SFU is going to work
its way into future MSFT OS releases as distributed. Whether this ultimately
keeps people using their OS, or makes it easier for people to switch, well,
time will tell...


> Plus, the win32 is so close to completion I can almost taste it... :)

Agreed :)

Cheers,
Claudio

---
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see
<a
href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em
ailpolicy.html</a>

Tom Lane wrote:
> Yeah, I was thinking while I read it that this license seems to have
no
> clue that it's for software that's being given away free :-(.
Obviously
> they have not changed it since SFU was a normal product.

I read some language somewhere that SFU uses the Client Access Licenses
model.  IOW, more than 10 connections require you to fork over some $$$.
Not sure about this point at all, though.  Also, this may not apply to
your own compiled software, just the services that come with SFU like
NFS.

> Until it occurs to Microsoft to adjust their license terms, the idea
of
> using SFU as part of the Postgres port seems to be right out.  Oh
well.

ISTM the SFU license has no bearing on postgresql, except it is a
proprietary build environment.  It is a stated objective to have
postgresql build on windows with open source tools as much as possible;
which alone justifies a hand rolled port vs. SFU (same as decision not
to use Visual Studio).  However the license of SFU itself is something
postgresql developers need not worry about, IMO (any more than we need
worry about cygwin licensing).

By the way, there postgres 7.2.2 has already been ported to SFU 3.5...
ftp://ftp.interopsystems.com/src/rcp/

It would be really interesting to benchmark this version vs. the
PeerDirect port.

Merlin

Merlin Moncure wrote:
> Dave Page wrote:
> > Steve Tibbett  wrote:
> > > Windows users will always prefer a Windows solution to a Unix
> > > solution running on SFU... I'd say sticking with the original
> > > goal of making a native Win32 version would be preferable.
> >
> > Plus I'll bet we couldn't distribute the required components ourselves
> > and would thus require the user to download interix first.
>
> Yes, but consider this:
> 1. from a windows developer's point of view, requiring Interix is no
> better or worse than requiring cygwin or mingw, except for maybe the
> size of the download/install.

FYI, we require mingw to compile PostgreSQL on Win32, not to run
PostgreSQL on Win32, right?

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian said:
> Merlin Moncure wrote:
>> Dave Page wrote:
>> > Steve Tibbett  wrote:
>> > > Windows users will always prefer a Windows solution to a Unix
>> > > solution running on SFU... I'd say sticking with the original goal
>> > > of making a native Win32 version would be preferable.
>> >
>> > Plus I'll bet we couldn't distribute the required components
>> > ourselves and would thus require the user to download interix first.
>>
>> Yes, but consider this:
>> 1. from a windows developer's point of view, requiring Interix is no
>> better or worse than requiring cygwin or mingw, except for maybe the
>> size of the download/install.
>
> FYI, we require mingw to compile PostgreSQL on Win32, not to run
> PostgreSQL on Win32, right?
>

Yes, of course. Otherwise we have all been wasting our time very badly ;-)

In fact, it's quite important that all work be tested from a Windows
command prompt, and not just from inside Mingw. I know I found numerous
errors that I corrected that way.

cheers

andrew

> Yes, of course. Otherwise we have all been wasting our time very badly
;-)
>
> In fact, it's quite important that all work be tested from a Windows
> command prompt, and not just from inside Mingw. I know I found
numerous
> errors that I corrected that way.

For fun, I've been porting postgres 7.4.1 to Interix and I'm about 99%
of the way through it.   There were some problems with configure and I
had to do a lot of things by hand.

It turns out that Interix 3.5 is still missing a few things, notably
sync() (but not threads)... :(.  I didn't know this going into it, and a
kernel based sync() was one of the major reasons that the Interix port
had the potential to be better/faster than a 'native' port (they do,
however have ipc & signals, and other helpful things).

So even if it was hypothetically possible to link to the interix libs
and release the port without the runtime installation (it isn't), we
would probably have chosen the current path anyways.

Still, the presence of Interix gives windows developers another
choice...because of the improved ipc support, it will probably outclass
the cygwin version.  In cases where SFU is already part of their IT
dept, it may be the best choice.

wrt MinGW, using it drives me crazy because it throws up console windows
that steal the focus when I am compiling.  Is their any way to prevent
this?

Merlin

Merlin Moncure said:
>
> wrt MinGW, using it drives me crazy because it throws up console
> windows that steal the focus when I am compiling.  Is their any way to
> prevent this?
>

I haven't seen this. What Windows platform are you on?

cheers

andrew

On Sat, Jan 24, 2004 at 12:34:42PM -0500, Merlin Moncure wrote:
> Still, the presence of Interix gives windows developers another
> choice...because of the improved ipc support, it will probably
> outclass the cygwin version.

Look Mom no cygipc! :,)

    http://cygwin.com/ml/cygwin-apps/2004-01/msg00179.html

Jason

--
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D  8784 1AFD E4CC ECF4 8EF6

> Merlin Moncure said:
> >
> > wrt MinGW, using it drives me crazy because it throws up console
> > windows that steal the focus when I am compiling.  Is their
> any way to
> > prevent this?
> >
>
> I haven't seen this. What Windows platform are you on?

I haven't either. Merlin, are you using it with msys?

Cheers,
Claudio

---
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see
<a
href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em
ailpolicy.html</a>

Andrew Dunstan wrote:
> Merlin Moncure said:
>
>>wrt MinGW, using it drives me crazy because it throws up console
>>windows that steal the focus when I am compiling.  Is their any way to
>>prevent this?
>>
I suppose you got the latest MSYS-1.0.10-rc#. Try getting the MSYS-1.0.9
release.

--
basic

> Andrew Dunstan wrote:
> > Merlin Moncure said:
> >
> >>wrt MinGW, using it drives me crazy because it throws up console
> >>windows that steal the focus when I am compiling.  Is their any way
to
> >>prevent this?
> >>
> I suppose you got the latest MSYS-1.0.10-rc#. Try getting the
MSYS-1.0.9
> release.


That did the trick...thanks.

Merlin

Merlin Moncure wrote:
> > Yes, of course. Otherwise we have all been wasting our time very badly
> ;-)
> >
> > In fact, it's quite important that all work be tested from a Windows
> > command prompt, and not just from inside Mingw. I know I found
> numerous
> > errors that I corrected that way.
>
> For fun, I've been porting postgres 7.4.1 to Interix and I'm about 99%
> of the way through it.   There were some problems with configure and I
> had to do a lot of things by hand.
>
> It turns out that Interix 3.5 is still missing a few things, notably
> sync() (but not threads)... :(.  I didn't know this going into it, and a
> kernel based sync() was one of the major reasons that the Interix port
> had the potential to be better/faster than a 'native' port (they do,
> however have ipc & signals, and other helpful things).

MinGW doesn't have sync() either.  It is on our TODO and I think we are
going to have to collect a list of files modified since the last
checkpoint and do an open/_commit on each one.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073