As far as i know, Saudi Arabia is at UTC+3h and has no daylight savings time, so
AST 10800 AST 10800
should do. (C.f. Arizona.)
--- Den mån 2008-04-21 skrev John Waters <[EMAIL PROTECTED]>:
> Från: John Waters <[EMAIL PROTECTED]>
> Ämne: [9fans] Timezone file for Riyadh, KSA
> Till: 9fans@9fan
Hello and good morning,
I have recently relocated to Riyadh, KSA and have decided to spend my
now all-too-copious free time learning the ins and outs of Plan 9. One
nagging problem for me, however, is the lack of a AST timezone file.
I am curious if it is at all possible for:
1) Someone to throw
On Mon, Apr 21, 2008 at 4:32 PM, John Waters <[EMAIL PROTECTED]> wrote:
> Hello and good morning,
> I have recently relocated to Riyadh, KSA and have decided to spend my
> now all-too-copious free time learning the ins and outs of Plan 9. One
> nagging problem for me, however, is the lack of a A
Hi gas,
After reviewing ctime's man page I came to the same conclusion.
I just tried it out and it appears to be just smurfy.
Thanks all,
jcw
On 4/21/08, gas <[EMAIL PROTECTED]> wrote:
> As far as i know, Saudi Arabia is at UTC+3h and has no daylight savings time,
> so
>
> AST 10800 AST 10800
>
On Thu Apr 17 19:07:09 EDT 2008, [EMAIL PROTECTED] wrote:
> anyway, perhaps the more important question, at least for erik, is: will
> his change cause trouble elsewhere? unfortunately, we don't know, but we'll
> see how he gets along!
>
not setting the PSH bit when there's no data does fix the
> i can only assume that they are trying to
> defend against some sort of dos attack. perhaps someone has a better
> suggestion?
it depends what they actually are running on that machine.
i've seen several broken tcp/ip implementations in embedded systems.
fairly often they mess up handling of t
Re Timezone file format:
/n/sources/contrib/steve/rc/tzdump
-Steve
On Mon, 21 Apr 2008 10:56:42 EDT erik quanstrom <[EMAIL PROTECTED]> wrote:
...
> bwc points out that godaddy's behavior is very likely a violation of the rfc.
I am not convinced any rfc covers this situation - it may be
that their tcp layer does the right thing and the bug is at
the application l
> `PUSH' is a curious anachronism considered indispensable by
> certain members of the Internet community. Since PUSH can
> (and does) change in any datagram, an information preserving
> compression scheme must pass it explicitly.
psh might be harder to understand than pre
> psh might be harder to understand than preserving message boundaries, but,
> hey,
> it's less useful and easier to get wrong.
absolutely!
worrying, isn't it.
> But in any case setting PSH on a
> packet with no data serves no real purpose.
i think that's incorrect: it ensures a push of any data that is already
buffered but un-pushed
(ie, the immediately preceding segment had no PSH, and the receiver's
implementation buffers
accordingly).
part of the
> But in any case setting PSH on a
> packet with no data serves no real purpose.
i think that's incorrect: it ensures a push of any data that is already
buffered but un-pushed
(ie, the immediately preceding segment had no PSH, and the receiver's
implementation buffers
accordingly).
part of the
On Mon, 21 Apr 2008 21:19:33 BST Charles Forsyth <[EMAIL PROTECTED]> wrote:
> > But in any case setting PSH on a
> > packet with no data serves no real purpose.
>
> i think that's incorrect: it ensures a push of any data that is already buffe
> red but un-pushed
> (ie, the immediately preceding
> must not buffer data indefinitely, and (2) MUST set the
> PSH bit in the last buffered segment (i.e., when there
> is no more queued data to be sent).
>
> The implication is that the "preceding segment" to a pkt with
> no data *will have* PSH set.
so does the implementation do th
Charles Forsyth wrote:
computing is needlessly regressing.
And it will continue to regress until one knowledgeable and independent
human being serves as final arbiter of standards.
> Charles Forsyth wrote:
> > computing is needlessly regressing.
> >
>
> And it will continue to regress until one knowledgeable and independent
> human being serves as final arbiter of standards.
>
good idea. why don't you ask ken?
- erik
> I meant this:
> /* Pull out data to send */
> bp = nil;
> if(dsize != 0) {
> bp = qcopy(s->wq, dsize, sent);
> if(BLEN(bp) != dsize) {
> seg.flags |= FIN;
>
> And it will continue to regress until one knowledgeable and independent
> human being serves as final arbiter of standards.
i think some of it eventually will be formalised, much as we do with programming
languages (even Javascript, which i mentioned, at least has a plausible
grammar),
but it
erik quanstrom wrote:
Charles Forsyth wrote:
computing is needlessly regressing.
And it will continue to regress until one knowledgeable and independent
human being serves as final arbiter of standards.
good idea. why don't you ask ken?
-
On Mon, 21 Apr 2008 22:24:35 BST Charles Forsyth <[EMAIL PROTECTED]> wrote:
> > must not buffer data indefinitely, and (2) MUST set the
> > PSH bit in the last buffered segment (i.e., when there
> > is no more queued data to be sent).
> >
> > The implication is that the "preceding
On Mon, 21 Apr 2008 17:49:35 EDT erik quanstrom <[EMAIL PROTECTED]> wrote:
> > I meant this:
> > /* Pull out data to send */
> > bp = nil;
> > if(dsize != 0) {
> > bp = qcopy(s->wq, dsize, sent);
> > if
having looked again at ip/tcp.c i think the code wasn't really intending
to resolve one of the stalled receiver cases i had in mind, although it happens
to do so,
so changing it probably doesn't mess up some original intent.
mind you, one lesson i take from all this is that in retrospect one coul
22 matches
Mail list logo
