Full GUID support

On sön, 2011-07-03 at 13:42 -0500, Michael Gould wrote:

I would like to request that full support for the UUID data type can added.
I think that even though there is a contrib module, since this is a standard
datatype that Postgres ought to be the one actually assigning the value.

What difference would that make? In 9.1, you can easily load the
required extension, and there'd be no difference from a built-in
variant.

Peter,

I don't believe that the library that the contrib module runs with can run
on Window 64 bit servers or even Windows 7 64 bit. That is problem as most
shops are using 64 bit OS and if Window the contrib module is going to fail.
Taking the responsibility to handle this internally means that you can
write your own implementation not based on a libary that can't handle
Windows 64 bit.

Best Regards

Michael Gould

"Peter Eisentraut" wrote:

On sön, 2011-07-03 at 13:42 -0500, Michael Gould wrote:

I would like to request that full support for the UUID data type can

added.

I think that even though there is a contrib module, since this is a

standard

datatype that Postgres ought to be the one actually assigning the value.

What difference would that make? In 9.1, you can easily load the
required extension, and there'd be no difference from a built-in
variant.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

--
Michael Gould, Managing Partner
Intermodal Software Solutions, LLC
904.226.0978
904.592.5250 fax

On Sunday, July 3, 2011, Michael Gould
<mgould@intermodalsoftwaresolutions.net> wrote:
&gt; Peter,
&gt;
&gt; I don't believe that the library that the contrib module runs with can run
&gt; on Window 64 bit servers or even Windows 7 64 bit.  That is problem as most
&gt; shops are using 64 bit OS and if Window the contrib module is
going to fail.
&gt;  Taking the responsibility to handle this internally means that you can
&gt; write your own implementation not based on a libary that can't handle
&gt; Windows 64 bit.

The next release of the installers will, now that we have a 64 Windows
port of ossp-uuid.

Even If that weren't the case, integrating the type wouldn't fix the
problem anyway, unless you're suggesting we implement our own UUID
generator (which isn't nearly as straightforward as it might seem, as
I understand it)..

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Dave Page <dpage@pgadmin.org> writes:

Even If that weren't the case, integrating the type wouldn't fix the
problem anyway, unless you're suggesting we implement our own UUID
generator (which isn't nearly as straightforward as it might seem, as
I understand it)..

Yeah. If there were One True Way to create a UUID, I would probably
agree that we should push that functionality into core. But there are
a lot of ways (and the reason for that is that they all suck in one
fashion or another :-(). Between that and the lack of portability of
many of the better ways, this is something I'm happy to keep at arm's
length.

Michael: this is something that was discussed before, when we agreed
to put the uuid type but not the generator functions in core. See
the archives. Nothing about the situation has changed since then.

regards, tom lane

Does this look to be something that will surface around for 9.1

Sent from Samsung mobile

Dave Page <dpage@pgadmin.org> wrote:

Should be in 9.0.5/9.1b3

On Sunday, July 3, 2011, Michael Gould
<mgould@intermodalsoftwaresolutions.net> wrote:
&gt; Does this look to be something that will surface around for 9.1
&gt;
&gt; Sent from Samsung mobile
&gt;
&gt; Dave Page &lt;dpage@pgadmin.org&gt; wrote:
&gt;
&gt;&gt;On Sunday, July 3, 2011, Michael Gould
&gt;&gt;&lt;mgould@intermodalsoftwaresolutions.net&gt; wrote:
&gt;&gt;&amp;gt; Peter,
&gt;&gt;&amp;gt;
&gt;&gt;&amp;gt; I don't believe that the library that the contrib
module runs with can run
&gt;&gt;&amp;gt; on Window 64 bit servers or even Windows 7 64 bit.
That is problem as most
&gt;&gt;&amp;gt; shops are using 64 bit OS and if Window the contrib module is
&gt;&gt;going to fail.
&gt;&gt;&amp;gt;  Taking the responsibility to handle this internally
means that you can
&gt;&gt;&amp;gt; write your own implementation not based on a libary
that can't handle
&gt;&gt;&amp;gt; Windows 64 bit.
&gt;&gt;
&gt;&gt;The next release of the installers will, now that we have a 64 Windows
&gt;&gt;port of ossp-uuid.
&gt;&gt;
&gt;&gt;Even If that weren't the case, integrating the type wouldn't fix the
&gt;&gt;problem anyway, unless you're suggesting we implement our own UUID
&gt;&gt;generator (which isn't nearly as straightforward as it might seem, as
&gt;&gt;I understand it)..
&gt;&gt;
&gt;&gt;--
&gt;&gt;Dave Page
&gt;&gt;Blog: http://pgsnake.blogspot.com
&gt;&gt;Twitter: @pgsnake
&gt;&gt;
&gt;&gt;EnterpriseDB UK: http://www.enterprisedb.com
&gt;&gt;The Enterprise PostgreSQL Company
&gt;&gt;
&gt;&gt;--
&gt;&gt;Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
&gt;&gt;To make changes to your subscription:
&gt;&gt;http://www.postgresql.org/mailpref/pgsql-hackers
&gt;

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Dave,

This is wonderful news.

Best Regards

Michael Gould

"Dave Page" <dpage@pgadmin.org> wrote:

Should be in 9.0.5/9.1b3

On Sunday, July 3, 2011, Michael Gould
<mgould@intermodalsoftwaresolutions.net> wrote:

Does this look to be something that will surface around for 9.1

Sent from Samsung mobile

Dave Page <dpage@pgadmin.org> wrote:

On Sunday, July 3, 2011, Michael Gould
<mgould@intermodalsoftwaresolutions.net> wrote:

Peter,

I don't believe that the library that the contrib

module runs with can run

on Window 64 bit servers or even Windows 7 64 bit.

That is problem as most

shops are using 64 bit OS and if Window the contrib module is

going to fail.

 Taking the responsibility to handle this internally

means that you can

write your own implementation not based on a libary

that can't handle

Windows 64 bit.

The next release of the installers will, now that we have a 64 Windows
port of ossp-uuid.

Even If that weren't the case, integrating the type wouldn't fix the
problem anyway, unless you're suggesting we implement our own UUID
generator (which isn't nearly as straightforward as it might seem, as
I understand it)..

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

--
Michael Gould, Managing Partner
Intermodal Software Solutions, LLC
904.226.0978
904.592.5250 fax

On sön, 2011-07-03 at 17:02 -0400, Tom Lane wrote:

Yeah. If there were One True Way to create a UUID, I would probably
agree that we should push that functionality into core. But there are
a lot of ways (and the reason for that is that they all suck in one
fashion or another :-(). Between that and the lack of portability of
many of the better ways, this is something I'm happy to keep at arm's
length.

There is a standard, and it defines four ways to create UUIDs. AFAIR,
no one has ever claimed that there is another recognized way that we
don't support. So I don't think that's really the argument. The
argument was that we don't want to bother.

On 7/3/11 2:02 PM, Tom Lane wrote:

Yeah. If there were One True Way to create a UUID, I would probably
agree that we should push that functionality into core. But there are
a lot of ways (and the reason for that is that they all suck in one
fashion or another :-(). Between that and the lack of portability of
many of the better ways, this is something I'm happy to keep at arm's
length.

Also, I think that UUIDs fall into the class of "datatypes used by less
than 10% of users" which should always remain extensions. I'd consider
CITEXT for core before UUID.

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

On Sun, Jul 10, 2011 at 20:59, Josh Berkus <josh@agliodbs.com> wrote:

On 7/3/11 2:02 PM, Tom Lane wrote:

Yeah.  If there were One True Way to create a UUID, I would probably
agree that we should push that functionality into core.  But there are
a lot of ways (and the reason for that is that they all suck in one
fashion or another :-().  Between that and the lack of portability of
many of the better ways, this is something I'm happy to keep at arm's
length.

Also, I think that UUIDs fall into the class of "datatypes used by less
than 10% of users" which should always remain extensions.  I'd consider
CITEXT for core before UUID.

UUID *is* in core. It's just the generation functions that aren't.

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

Magnus Hagander <magnus@hagander.net> writes:

On Sun, Jul 10, 2011 at 20:59, Josh Berkus <josh@agliodbs.com> wrote:

Also, I think that UUIDs fall into the class of "datatypes used by less
than 10% of users" which should always remain extensions. I'd consider
CITEXT for core before UUID.

UUID *is* in core. It's just the generation functions that aren't.

Remind me again *why* it's in core? Seems like something that ought to
be an extension.

regards, tom lane

On mån, 2011-07-11 at 11:13 -0400, Tom Lane wrote:

Magnus Hagander <magnus@hagander.net> writes:

On Sun, Jul 10, 2011 at 20:59, Josh Berkus <josh@agliodbs.com> wrote:

Also, I think that UUIDs fall into the class of "datatypes used by less
than 10% of users" which should always remain extensions. I'd consider
CITEXT for core before UUID.

UUID *is* in core. It's just the generation functions that aren't.

Remind me again *why* it's in core? Seems like something that ought to
be an extension.

I think at the time, making something an add-on would have placed an
excessive burden on potential users. The claim was that most UUIDs are
generated by applications, so having the type in core would be
important, but having the generation functions not so much.

That said, there have been several proposals over the years to move a
few things out of the core into add-ons, and now that extension support
exists, we could potentially reopen that discussion.

Excerpts from Peter Eisentraut's message of lun jul 11 11:48:22 -0400 2011:

That said, there have been several proposals over the years to move a
few things out of the core into add-ons, and now that extension support
exists, we could potentially reopen that discussion.

Surely we ought to find a way to distribute binaries first, at least for
those platforms on which compiling stuff from source is cumbersome.

--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

On 07/10/2011 11:59 AM, Josh Berkus wrote:

On 7/3/11 2:02 PM, Tom Lane wrote:

Yeah. If there were One True Way to create a UUID, I would probably
agree that we should push that functionality into core. But there are
a lot of ways (and the reason for that is that they all suck in one
fashion or another :-(). Between that and the lack of portability of
many of the better ways, this is something I'm happy to keep at arm's
length.

Also, I think that UUIDs fall into the class of "datatypes used by less
than 10% of users" which should always remain extensions. I'd consider
CITEXT for core before UUID.

Uh.... UUID/GUID is used pervasively throughout enterprise apps,
especially Java apps.

--
Command Prompt, Inc. - http://www.commandprompt.com/
PostgreSQL Support, Training, Professional Services and Development
The PostgreSQL Conference - http://www.postgresqlconference.org/
@cmdpromptinc - @postgresconf - 509-416-6579

I'd have to agree on the importance of UUID support. It's pretty much
essential for any sort of disconnected sync model. We use UUIDs
(generated with the "guid.comb" technique) for our surrogate keys in
around 50 apps, and it has served us well.

We have also been seriously missing the 64-bit generator
functionality. I've been watching the threads for half a year to see
when it will pop up again. It's been a long wait.

Regarding UUID generation, IMHO, the random approach is the "standard"
at this point. That'd be v4 in the oisp library. It would be handy
to be able to generate these without having to load in special
extensions. It's not the biggest deal though since we can run
initialization code to get the database set up... just more effort.

Patrick Earl

On 07/03/2011 11:54 AM, Peter Eisentraut wrote:

On sön, 2011-07-03 at 13:42 -0500, Michael Gould wrote:

I would like to request that full support for the UUID data type can added.
I think that even though there is a contrib module, since this is a standard
datatype that Postgres ought to be the one actually assigning the value.

What difference would that make? In 9.1, you can easily load the
required extension, and there'd be no difference from a built-in
variant.

It is about usability folks.

--
Command Prompt, Inc. - http://www.commandprompt.com/
PostgreSQL Support, Training, Professional Services and Development
The PostgreSQL Conference - http://www.postgresqlconference.org/
@cmdpromptinc - @postgresconf - 509-416-6579

On 07/12/2011 12:03 PM, Joshua D. Drake wrote:

On 07/03/2011 11:54 AM, Peter Eisentraut wrote:

On sön, 2011-07-03 at 13:42 -0500, Michael Gould wrote:

I would like to request that full support for the UUID data type can
added.
I think that even though there is a contrib module, since this is a
standard
datatype that Postgres ought to be the one actually assigning the
value.

What difference would that make? In 9.1, you can easily load the
required extension, and there'd be no difference from a built-in
variant.

It is about usability folks.

What about extensions makes them less usable?

cheers

andrew

Magnus, JD,

UUID *is* in core. It's just the generation functions that aren't.

No, it's not. It's in /contrib, which makes it an extension.

Uh.... UUID/GUID is used pervasively throughout enterprise apps,
especially Java apps.

Oh, I guess I encounter it a lot less than you. Time for a survey?

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

On 12 July 2011 19:24, Josh Berkus <josh@agliodbs.com> wrote:

Magnus, JD,

UUID *is* in core. It's just the generation functions that aren't.

No, it's not.  It's in /contrib, which makes it an extension.

The functions to produce UUIDs are in contrib, but the UUID data type
itself is in core. You get the type uuid whether you install the
contrib module or not.

http://www.postgresql.org/docs/current/static/datatype-uuid.html

--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Jul 12, 2011, at 1:24 PM, Josh Berkus <josh@agliodbs.com> wrote:

Magnus, JD,

UUID *is* in core. It's just the generation functions that aren't.

No, it's not. It's in /contrib, which makes it an extension.

Uh.... UUID/GUID is used pervasively throughout enterprise apps,
especially Java apps.

Oh, I guess I encounter it a lot less than you. Time for a survey?

How about we just leave it alone? I think this is a solution in search of a problem.

...Robert

Thom,

The functions to produce UUIDs are in contrib, but the UUID data type
itself is in core. You get the type uuid whether you install the
contrib module or not.

http://www.postgresql.org/docs/current/static/datatype-uuid.html

Oh!

I guess that shows you how much I use the type then.

Well, in that case, this whole discussion is moot unless someone is
offering to write us a UUID generator from scratch. Is someone doing so?

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

On 07/12/2011 11:56 AM, Josh Berkus wrote:

Thom,

The functions to produce UUIDs are in contrib, but the UUID data type
itself is in core. You get the type uuid whether you install the
contrib module or not.

http://www.postgresql.org/docs/current/static/datatype-uuid.html

Oh!

I guess that shows you how much I use the type then.

Well, in that case, this whole discussion is moot unless someone is
offering to write us a UUID generator from scratch. Is someone doing so?

I am reaching back into my mental archives for when we first decided to
implement a UUID datatype. As I recall we purposely did not include the
generators in core because every language already has their own
generators, popular languages anyway.

I think we should just leave it as be, note to use your native language
generator OR use the contributed modules.

JD

--
Command Prompt, Inc. - http://www.commandprompt.com/
PostgreSQL Support, Training, Professional Services and Development
The PostgreSQL Conference - http://www.postgresqlconference.org/
@cmdpromptinc - @postgresconf - 509-416-6579

On 07/12/2011 09:15 AM, Andrew Dunstan wrote:

On 07/12/2011 12:03 PM, Joshua D. Drake wrote:

On 07/03/2011 11:54 AM, Peter Eisentraut wrote:

On sön, 2011-07-03 at 13:42 -0500, Michael Gould wrote:

I would like to request that full support for the UUID data type can
added.
I think that even though there is a contrib module, since this is a
standard
datatype that Postgres ought to be the one actually assigning the
value.

What difference would that make? In 9.1, you can easily load the
required extension, and there'd be no difference from a built-in
variant.

It is about usability folks.

What about extensions makes them less usable?

It is an extra step, that is less usable. Does it matter? Shrug, I know
I hate having to type apt-get just to use xyz, does it mean it is a big
deal? Probably not.

--
Command Prompt, Inc. - http://www.commandprompt.com/
PostgreSQL Support, Training, Professional Services and Development
The PostgreSQL Conference - http://www.postgresqlconference.org/
@cmdpromptinc - @postgresconf - 509-416-6579

On 07/12/2011 03:44 PM, Joshua D. Drake wrote:

What about extensions makes them less usable?

It is an extra step, that is less usable. Does it matter? Shrug, I
know I hate having to type apt-get just to use xyz, does it mean it is
a big deal? Probably not.

By that argument we wouldn't have any extensions at all, just a
monolithic product. I don't think that would be an advance.

cheers

andrew

On Tue, Jul 12, 2011 at 04:29:33PM -0400, Andrew Dunstan wrote:

On 07/12/2011 03:44 PM, Joshua D. Drake wrote:

What about extensions makes them less usable?

It is an extra step, that is less usable. Does it matter? Shrug, I
know I hate having to type apt-get just to use xyz, does it mean
it is a big deal? Probably not.

By that argument we wouldn't have any extensions at all, just a
monolithic product. I don't think that would be an advance.

cheers

andrew

For me, the criteria I like to use for core functionality are:

1. It is available with a common definition from a number of DB products.
With a UUID, it's size/structure is predefined and this allows a dump from
another SQL product to be loaded into a PostgreSQL DB.

2. It would benefit from the tighter integration with the core DB for
either performance or development use.

3. It is a feature where the "extra step" is an unexpected nuisance.

That is why I think having the UUID generators be a contrib module
is the correct place for them to be, but the UUID type is better as
a core function.

Regards,
Ken

On 07/12/2011 01:29 PM, Andrew Dunstan wrote:

On 07/12/2011 03:44 PM, Joshua D. Drake wrote:

What about extensions makes them less usable?

It is an extra step, that is less usable. Does it matter? Shrug, I
know I hate having to type apt-get just to use xyz, does it mean it is
a big deal? Probably not.

By that argument we wouldn't have any extensions at all, just a
monolithic product. I don't think that would be an advance.

By that argument, with a condition of what we are talking about. I think
what this boils down to is we look at what our competitors are doing. If
we were to change anything at all.

cheers

andrew

--
Command Prompt, Inc. - http://www.commandprompt.com/
PostgreSQL Support, Training, Professional Services and Development
The PostgreSQL Conference - http://www.postgresqlconference.org/
@cmdpromptinc - @postgresconf - 509-416-6579

On Jul 12, 2011, at 1:40 PM, ktm@rice.edu wrote:

That is why I think having the UUID generators be a contrib module
is the correct place for them to be, but the UUID type is better as
a core function.

I'm okay with this, though given the fact that ftp.ossp.org has been down for *months*, I'm inclined to think that we ought to include it in the contrib distribution for easy linking.

Best,

David

David,

I'm okay with this, though given the fact that ftp.ossp.org has been down for *months*, I'm inclined to think that we ought to include it in the contrib distribution for easy linking.

What license is it under?

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

"David E. Wheeler" <david@kineticode.com> writes:

On Jul 12, 2011, at 1:40 PM, ktm@rice.edu wrote:

That is why I think having the UUID generators be a contrib module
is the correct place for them to be, but the UUID type is better as
a core function.

I'm okay with this, though given the fact that ftp.ossp.org has been
down for *months*,

Curious considering that the machine is there (responds to ping), and
the ossp.org webserver works fine. Has anyone bugged the owner about
that?

I'm inclined to think that we ought to include it in the contrib distribution for easy linking.

I'm disinclined to do anything that might amount to forking the library,
or even looking like we wanted to take responsibility for it.

regards, tom lane

On Jul 12, 2011, at 5:07 PM, Tom Lane wrote:

Curious considering that the machine is there (responds to ping), and
the ossp.org webserver works fine. Has anyone bugged the owner about
that?

I've sent him email and Twitter DMs, to no avail.

Best,

David

On Jul 12, 2011, at 5:06 PM, Josh Berkus wrote:

I'm okay with this, though given the fact that ftp.ossp.org has been down for *months*, I'm inclined to think that we ought to include it in the contrib distribution for easy linking.

What license is it under?

COPYRIGHT AND LICENSE

Copyright (c) 2004-2008 Ralf S. Engelschall <rse@engelschall.com>
Copyright (c) 2004-2008 The OSSP Project <http://www.ossp.org/&gt;

This file is part of OSSP uuid, a library for the generation
of UUIDs which can found at http://www.ossp.org/pkg/lib/uuid/

Permission to use, copy, modify, and distribute this software for
any purpose with or without fee is hereby granted, provided that
the above copyright notice and this permission notice appear in all
copies.

THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL THE AUTHORS AND COPYRIGHT HOLDERS AND THEIR
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
SUCH DAMAGE.

Um, Although I have not caught up with this thread.

Ralf-san and the member of OSSP are maintaining OSSP continuously.
I think that a reaction can merely be obtained in the intervals of when
busy. Please do not need fast response.

(2011/07/13 11:35), David E. Wheeler wrote:

On Jul 13, 2011, at 6:44 AM, Hiroshi Saito wrote:

Um, Although I have not caught up with this thread.

Ralf-san and the member of OSSP are maintaining OSSP continuously.
I think that a reaction can merely be obtained in the intervals of when busy. Please do not need fast response.

I have not been able to connect to ftp.ossp.org for months. Months.

David

Hi Thomas-san, Ralf-san.

I appreciate your great work.
Thanks!

CC to Postgres-ML.

Regards,
Hiroshi Saito

(2011/07/14 3:49), Thomas Lotterer wrote:

On Jul 14, 2011, at 12:05 AM, Hiroshi Saito wrote:

Hi Thomas-san, Ralf-san.

I appreciate your great work.
Thanks!

CC to Postgres-ML.

Regards,
Hiroshi Saito

(2011/07/14 3:49), Thomas Lotterer wrote:

Thanks for the hint.
Our ftp daemon is dumping core.
We are debugging ...

Ah, good news, thanks.

Where should I report stuff like this in the future? I sent a message about this to rse@engelschall.com on May 15th and also a Twitter DM but didn't hear back…

Thanks,

David

On Jul 14, 2011, at 9:53 AM, David E. Wheeler wrote:

(2011/07/14 3:49), Thomas Lotterer wrote:

Thanks for the hint.
Our ftp daemon is dumping core.
We are debugging ...

Ah, good news, thanks.

Where should I report stuff like this in the future? I sent a message about this to rse@engelschall.com on May 15th and also a Twitter DM but didn't hear back…

Hi Thomas,

Did you ever get your FTP server fixed? I'm still not able to download uuid:

curl -O ftp://ftp.ossp.org/pkg/lib/uuid/uuid-1.6.2.tar.gz
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- 0:00:02 --:--:-- 0
curl: (7) couldn't connect to host

Thanks,

David