Re: Microsoft releses Services for Unix
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
Tom Lane wrote:
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.)
I suspect it would be somewhere in between. I can tell you from personal
experience that getting Cygwin into a large data centre can be very
hard, if not impossible. The techno-bureaucrats that run them can be
(understandably) very anal and paranoid about what they allow on their
machines. If you are running a bank or a nuclear power station it is the
only sensible way to be. (You might argue that banks and nuclear power
stations should not be controlled by Windows machines - but that's
another argument - let's not go there right now ;-)
I don't think I would have encountered as much resistance to getting
WSFU onto these machines - some, but not as much.
The licensing issue does affect companies like the one I used to work
for, that wanted to be able to bundle a database with the product.
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 ...
Not me :-)
* 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.
Agreed. I think this is worth exploring, but I don't think it's worth
stopping what we are doing right now while we explore.
Note that the migration guide says that threads are not supported. So if
we ever went to a threaded implementation we could not go down this path.
cheers
andrew
Note that the migration guide says that threads are not
supported. So if
we ever went to a threaded implementation we could not go
down this path.
POSIX threads are supported on the upcoming version 3.5... The migration
guide is apparantly not updated.
//Magnus
Import Notes
Resolved by subject fallback