Thread: 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 >
Attachment
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