Thread: "make report"
I'd like to implement *something* to help us collect information on what
platforms actually have what features. This would be useful, for
example, for figuring out whether any platforms are lacking 8 byte
integers or are missing timezone infrastructure.
I was thinking about something like "make report" which would mail the
results of ./configure to, say, the ports mailing list. We could mention
it in the text message printed at the end of the make cycle.
Comments? Suggestions?
- Thomas
> I'd like to implement *something* to help us collect information on what > platforms actually have what features. This would be useful, for > example, for figuring out whether any platforms are lacking 8 byte > integers or are missing timezone infrastructure. > > I was thinking about something like "make report" which would mail the > results of ./configure to, say, the ports mailing list. We could mention > it in the text message printed at the end of the make cycle. > > Comments? Suggestions? Suggestion: Why not embed this information into the binary, and provide some way of extracting it. (There's a Linux kernel option that allows something similar, so it wouldn't be something unprecedented.) If all the config information is embedded in the binary, automatically, at compile time, then this allows the ability to be _certain_ that: - "Oh, that was compiled with a really stupid set of compiler options; you'll have to recompile!" - "That was compiled without support for FOO, but with support for BAR." - "Announcement, people: Look out for whether or not your distribution compiled PostgreSQL with proper support for 64 bit integers. Several distributions got this wrong with the 7.4.17 release, and you can see if it's OK by looking for LONG_LONG_REVISED in the embedded configuration information." [Downside: "Announcement, script kiddies: If you find option UPDATE_DESCR_TABS=1 in the configuration information, then there's a very easy root exploit..."] -- (reverse (concatenate 'string "gro.gultn@" "enworbbc")) http://www3.sympatico.ca/cbbrowne/x.html Rules of the Evil Overlord #176. "I will add indelible dye to the moat. It won't stop anyone from swimming across, but even dim-witted guards should be able to figure out when someone has entered in this fashion." <http://www.eviloverlord.com/> -- (concatenate 'string "cbbrowne" "@acm.org") http://www3.sympatico.ca/cbbrowne/spiritual.html Including a destination in the CC list that will cause the recipients' mailer to blow out is a good way to stifle dissent. -- from the Symbolics Guidelines for Sending Mail
On Tue, 23 Apr 2002 cbbrowne@cbbrowne.com wrote: > Suggestion: Why not embed this information into the binary, and > provide some way of extracting it. I like this! > [Downside: "Announcement, script kiddies: If you find option > UPDATE_DESCR_TABS=1 in the configuration information, then there's a > very easy root exploit..."] That's not a downside at all. If an exploit exists, you need only try it, and it works or it doesn't. In fact, it's an upside becuase it allows someone who doesn't have exploit code more easily to determine whether or not he might be vulnerable. cjs -- Curt Sampson <cjs@cynic.net> +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're alllight. --XTC
Thomas Lockhart <lockhart@fourpalms.org> writes:
> I was thinking about something like "make report" which would mail the
> results of ./configure to, say, the ports mailing list. We could mention
> it in the text message printed at the end of the make cycle.
I think it'd be a bad idea to encourage people to send mail to the ports
list. For one thing, a pile of nonsubscriber mail would make more work
for Marc, who has quite enough already. If you want to do this, set up
a dedicated mail alias to receive such reports.
(Possibly my thoughts on soliciting mass email are a tad colored by the
amount of virus traffic I've been seeing lately :-( ... if the Klez
epidemic gets any worse I will be forced to shut down jpeg-info, which
is currently seeing upwards of 1000 virus mails/day...)
I do like Joe's idea of embedding a complete configuration report
right into the backend executable, where it can be retrieved long
after config.log has been thrown away.
regards, tom lane
Thomas Lockhart writes: > I'd like to implement *something* to help us collect information on what > platforms actually have what features. This would be useful, for > example, for figuring out whether any platforms are lacking 8 byte > integers or are missing timezone infrastructure. I don't think that's very useful. Most configuration checks are there because some platform needed them at one point. (Some are not -- that's a different story.) Those platforms do not go away, and receiving thousands of reports about "I have feature X" won't prove that there are no systems without feature X. If you want to collect information about what features are portable you can check other software packages, product manuals, ports trees, etc. Most issues are documented someplace. Btw., yes, 8 byte integers are missing on some platforms. -- Peter Eisentraut peter_e@gmx.net
> If you want to collect information about what features are portable you
> can check other software packages, product manuals, ports trees, etc.
> Most issues are documented someplace.
Oh goodness. Thanks for offering me a new hobby ;)
> Btw., yes, 8 byte integers are missing on some platforms.
Right. The two areas which come to mind are integer availability and the
timezone support (as you might know we support *three* different time
zone models). At the moment, none of the developers know the features
supported on the platforms we claim to support. Which platforms do not
have int8 support still? Which do not have time zone interfaces fitting
into the two "zonefull" styles? I'd like to know, but istm that the
people *with* the platforms could do this much more easily than those
without. What am I missing here??
- Thomas
Thomas Lockhart writes: > Right. The two areas which come to mind are integer availability and the > timezone support (as you might know we support *three* different time > zone models). At the moment, none of the developers know the features > supported on the platforms we claim to support. Which platforms do not > have int8 support still? "Still" is the wrong word. There used to be platforms with certain areas of trouble, and those platforms don't go away. But since you asked: QNX 4 and SCO OpenServer are known to lack 8 byte integers. > Which do not have time zone interfaces fitting > into the two "zonefull" styles? I'd like to know, but istm that the > people *with* the platforms could do this much more easily than those > without. What am I missing here?? I don't think polling users this way will yield reliable results. If you really want to find out, break something and see if someone complains. -- Peter Eisentraut peter_e@gmx.net
It depends. QNX4 may be used with GCC, in which case it does have long long. I am not sure if that combination will play along with Postgres, but it should not be assumed impossible. ----- Original Message ----- From: "Peter Eisentraut" <peter_e@gmx.net> To: "Thomas Lockhart" <lockhart@fourpalms.org> Cc: "PostgreSQL Hackers" <pgsql-hackers@postgresql.org> Sent: Wednesday, April 24, 2002 1:14 PM Subject: Re: [HACKERS] "make report" > Thomas Lockhart writes: > > > Right. The two areas which come to mind are integer availability and the > > timezone support (as you might know we support *three* different time > > zone models). At the moment, none of the developers know the features > > supported on the platforms we claim to support. Which platforms do not > > have int8 support still? > > "Still" is the wrong word. There used to be platforms with certain areas > of trouble, and those platforms don't go away. > > But since you asked: QNX 4 and SCO OpenServer are known to lack 8 byte > integers. > > > Which do not have time zone interfaces fitting > > into the two "zonefull" styles? I'd like to know, but istm that the > > people *with* the platforms could do this much more easily than those > > without. What am I missing here?? > > I don't think polling users this way will yield reliable results. If you > really want to find out, break something and see if someone complains. > > -- > Peter Eisentraut peter_e@gmx.net > > > ---------------------------(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 >
Igor Kovalenko writes: > It depends. QNX4 may be used with GCC, in which case it does have long long. > I am not sure if that combination will play along with Postgres, but it > should not be assumed impossible. The point is, it should not be assumed possible. -- Peter Eisentraut peter_e@gmx.net