Re: [9fans] SHA-1 collision and venti

On 26 February 2017 at 17:25, Bakul Shah wrote: > Venti is similarly corruptible, right? Since the checksum is over just the > content. If you downloaded https://shattered.io/static/shattered-1.pdf > and > https://shattered.io/static/shattered-2.pdf,

Re: [9fans] SHA-1 collision and venti

It's curious that svn "corrupts" the repository, if that's really what they mean, when two leaf files collide. An index or directory colliding with a file would be more understandable. On 26 February 2017 at 18:16, Charles Forsyth wrote: > > On 26 February 2017 a

Re: [9fans] SHA-1 collision and venti

On 26 February 2017 at 17:30, Jules Merit wrote: > there is a backdoor when a score of 4, what data produces it i have no > idea. > where is that? I had a quick look but couldn't find it.

Re: [9fans] SHA-1 collision and venti

On Sun, 26 Feb 2017, 18:49 Bakul Shah, wrote: > The links are to different files. > Not on Gmail at least look to see where each link points. Both are to -2 in the message I see on Gmail. Unless it cleverly optimised the"identical" content!

Re: [9fans] SHA-1 collision and venti

On 27 February 2017 at 15:46, Dave MacFarlane wrote: > Why not skip sha-256 and go directly to Sha3? blake2 has also been suggested

Re: [9fans] SHA-1 collision and venti

On 27 February 2017 at 16:47, Charles Forsyth wrote: > On 27 February 2017 at 15:46, Dave MacFarlane wrote: > >> Why not skip sha-256 and go directly to Sha3? > > > blake2 has also been suggested also, it's not clear it's urgent for venti. the scam is to mak

Re: [9fans] SHA-1 collision and venti

On 27 February 2017 at 17:28, Bakul Shah wrote: > My argument is that an archival system that can't store some files, no > matter how they were generated, is not good enough. A hash collision > researcher may have a legitimate reason to store such files. > that's a separate argument that venti

Re: [9fans] SHA-1 collision and venti

On 27 February 2017 at 18:30, Charles Forsyth wrote: > that's a separate argument that venti would never work for you, regardless > of the hash algorithm used. since venti returns the resulting score from each write, and it knows whether there's been a collision, it appears i

Re: [9fans] SHA-1 collision and venti

lies on that > behavior. > As for venti, I wouldn't say 'no point' to an algorithm update, but > I'd rather have fossil updated to manage to deal with collisions > better first. > > > On Mon, Feb 27, 2017 at 8:14 PM, Bakul Shah wrote: > > On Mon, 27

Re: [9fans] coherence function in kernel (especially in raspberry pi port)

On 28 March 2017 at 19:21, yoann padioleau wrote: > For example I see this code in bcm/taslock.c > > coherence(); > l->key = 0; > coherence(); > > bcm/taslock.c seems actually mostly a copy paste of port/taslock.c > with an extra call to coherence before the assignment abo

Re: [9fans] coherence function in kernel (especially in raspberry pi port)

On 28 March 2017 at 19:21, yoann padioleau wrote: > but I fail to understand the meaning of S and B. Synchronisation Barrier

Re: [9fans] pipe: bug or feature?

On 28 March 2017 at 01:05, arisawa wrote: > the program reads a file and writes it to one end of pipe and then reads > it from another end of pipe. > the buffer for writing pipe is named buf0, and for reading pipe is named > buf. > The general problem with this is that a pipe is a full-duplex co

Re: [9fans] Starting rio on combined CPU, file and auth

On 5 May 2017 at 02:22, Alex Musolino wrote: > > "CPU servers typically don't have any reason to run rio on a local draw > device." > I don't even bother including the draw device and hangers-on in cpu servers.

Re: [9fans] equality sign in Rc

On 13 May 2017 at 13:36, trebol wrote: > Then I used troff to write a paper, and surprise!, there is no utf8 > support. I'm fairly sure there is in troff.

Re: [9fans] equality sign in Rc

On 13 May 2017 at 15:21, trebol wrote: > No with hyphenation, my friend! ahh! that's a little more specific. I usually switch it off so I wouldn't have noticed.

Re: [9fans] equality sign in Rc

On 13 May 2017 at 13:36, trebol wrote: > You can force rc to setting a variable only if = is surrounded by spaces, > like in sh, but then you'll have a lot of problems in plan9/p9p. That isn't sh's rule. x=y is fine as an assignment without spaces. Shell/environment variable assignments appear

Re: [9fans] equality sign in Rc

Given > broken! one=1 two=2 echo $one $two > 1 2 > What should the following do? one=1 echo two=2 $one $two Disregarding a UNIX historical mistake, I'd expect 1 2 > broken! echo one=1 > one=1 >

Re: [9fans] Blocking on write

On 15 May 2017 at 11:05, Giacomo Tesio wrote: > Is there any fs/device in Plan9 that can easily provide such behaviour? Bind #| to a name and fill up one of the data files (blocks at 256k on my system, might be 32k on small ones).

Re: [9fans] equality sign in Rc

The original aim was to implement named parameters that the shell would parse and pass to the command. That was frustrated in UNIX because there was one command (dd) that used = in its syntax. There are no such commands in Plan 9, except mk, but mk is interesting because mk treats those as entries

Re: [9fans] equality sign in Rc

On 15 May 2017 at 12:54, Charles Forsyth wrote: > = would be handled by rc uniformly. Just as file name patterns are handled by the shell for all commands.

Re: [9fans] equality sign in Rc

On 15 May 2017 at 12:54, Charles Forsyth wrote: > and = would be handled by rc uniformly. It also wouldn't break anything, because nothing currently can use unquoted =, and things that used quoted = would work just as before.

Re: [9fans] equality sign in Rc

On 15 May 2017 at 16:37, Erik Quanstrom wrote: > I implemented the Unix mistake as this hack is for p9p. I'm not sure I > like it. it's interesting to note that = is still not allowed in a list. Great. So now there are two different rc conventions. perhaps {} should be treated specially after

Re: [9fans] equality sign in Rc

On 15 May 2017 at 16:54, Erik Quanstrom wrote: > if we implement the right thing, then arguments like --fu=bar will be > 'eaten silently' from the perspective of the (human) operator. sure gigo, > but this seems extra hard o get right in a Unix environment. It would be better then to leave thi

Re: [9fans] Blocking on write

On 15 May 2017 at 16:46, Giacomo Tesio wrote: > Shouldn't the waserror code check that the queue has been actually closed? Either that or check errstr against Ehungup, since that's the exact error it incurred. The latter has the advantage of not obscuring a different error if the pipe is closed

Re: [9fans] equality sign in Rc

On 15 May 2017 at 17:30, Giacomo Tesio wrote: > % echo "$--fu" > rc: null list in concatenation > wrong quotes. try echo $'--fu' h% --x=hello h% echo $'--x' hello

Re: [9fans] equality sign in Rc

On 15 May 2017 at 17:44, trebol wrote: > I suppose this is the perfect answer to my silly question: why not permit = > after the start of a command? > do that, but make it behave like = before the start of the command. rc provides the outer syntax for all commands, as it does for file matching a

Re: [9fans] equality sign in Rc

On 15 May 2017 at 19:33, trebol wrote: > $-fu must be equivalent to $^-fu, $^x is a syntax error, and not $x. $^x would be "whatever $ is" concatenated with literal "x" but "$" by itself is a syntax error

Re: [9fans] equality sign in Rc

On 15 May 2017 at 17:44, trebol wrote: > > = is part of rc syntax, like {} and (), and it interprets it, not the i'd forgotten about the = in >[2=1], so you'd need another exception ... rc would interpret that, but then in [a-b=] it presumably wouldn't again...

Re: [9fans] Killing another user's process

lower case kill restricts the list to processes of the invoking user initial cap Kill doesn't do that. for lower case kill, you can @{rfork n; echo -n none >/tmp/none && bind /tmp/none /dev/user && kill tftpd} you wouldn't normally of course but aspects of that command might be instructive On 25 J

Re: [9fans] Why Plan 9 uses $ifs instead of $IFS?

> > since for example the original Rc paper still referred to $IFS. really? the only references to IFS I can find are in comparisons of $ifs to the Bourne shell's $IFS On 17 October 2017 at 16:05, Giacomo Tesio wrote: > Really? Just aesthetics? :-o > I supposed it had some practical goal I was

Re: [9fans] Why Plan 9 uses $ifs instead of $IFS?

WAT! or should that be "wat!" On 17 October 2017 at 22:49, Jules Merit wrote: > Gun Control UTF8, sgi 0xfbc bowling for columbine > > On Tue, Oct 17, 2017 at 2:45 PM, Jules Merit > wrote: > > E4M1 Charles, dm > > E3M8 Dis 9/11 > > > > On Tue, Oct 17, 2017 at 2:12 PM, Jules Merit > > wrote:

Re: [9fans] R.I.P cs.bell-labs.com

0in...@gmail.com> wrote: > > Didn't Charles Forsyth have a github or similar such repository with a > copy > > of the Labs sources? That was even seeing sporadic updates? I'm sure I > > browsed it last fall, but I can't find it now. > > Few years

Re: [9fans] R.I.P cs.bell-labs.com

"we never know when plan9.bell-labs.com will be back." Yes, yes we do. Not. On 5 January 2018 at 16:35, David du Colombier <0in...@gmail.com> wrote: > > How about contrib? It would be nice to have something to fall back on > > when the plug is finally pulled. > > We could use the /n/sources/cont

Re: [9fans] Spectre and Meltdown

If Intel sells you lemons, make lemonade (ok, ok, at least a whiskey sour). I myself welcome our new speculative overlords, and look forward to new interesting predictions, and perhaps even a renewed interest in single-address space systems, since that's what we've got. On 10 January 2018 at 21:43

Re: [9fans] Acme create new file

Type B filename in the tag of an existing frame in the directory and execute it with button 2; or type B filename as a command in that directory in a win frame or rio window. On 13 May 2018 at 02:22, Chris McGee wrote: > Hi All, > > I’ve been using acme for a while and really enjoying the capab

Re: [9fans] A compiler bug

"6.6 Constant expressions" doesn't allow a cast from a non-arithmetic type to an arithmetic one generally, and a cast in an address constant can only cast from an integer constant to a pointer type (eg, char *reg = (char*)0x123450); the one example with 8c escaped with a warning ("initialize point

Re: [9fans] A compiler bug

Oh. I meant that I'd fix it. On Thu, 2 Aug 2018 at 01:29, Bakul Shah wrote: > On Aug 1, 2018, at 4:35 PM, Charles Forsyth > wrote: > > > even so, the format and intention of the example seems practical (with > the correct cast to uintptr) and "An implementation

Re: [9fans] A compiler bug

I've fixed the immediate problem I think in a local copy but I want to eliminate another difference between targets before publishing the change. On Thu, 2 Aug 2018 at 15:20, wrote: > > Fwiw, the bugs in 6c and 8c where the cast fails was fixed in 9front > > with https://code.9front.org/hg/plan9

Re: [9fans] Is Plan 9 C "Less Dangerous?"

The Plan 9 C compiler doesn't take an insane view of the meaning of "undefined behaviour", which makes a big difference. It also assumes you know how to write loops if they need to be fast (which frankly hasn't really mattered at the O/S level, esp on modern hardware), so it won't "optimise" essent

Re: [9fans] Is Plan 9 C "Less Dangerous?"

Plan 9 C implements C by attempting to follow the programmer's instructions, which is surprisingly useful in systems programming. The big fat compilers work hard to find grounds to interpret those instructions as "undefined behaviour". On Sun, 2 Sep 2018 at 17:32, Chris McGee wrote: > Hi All, >

Re: [9fans] PDP11 (Was: Re: what heavy negativity!)

Ideally, anyway. On Mon, 8 Oct 2018 at 11:20, hiro <23h...@gmail.com> wrote: > saving every bit of memory has costs in coding, the pressure wasn't as > strong any more. > the earned flexibility can be used for more elegant design. > >

Re: [9fans] zero copy & 9p (was Re: PDP11 (Was: Re: what heavy negativity!)

I did several versions of one part of zero copy, inspired by several things in x-kernel, replacing Blocks by another structure throughout the network stacks and kernel, then made messages visible to user level. Nemo did another part, on his way to Clive On Fri, 12 Oct 2018, 07:05 Ori Bernstein, w

Re: [9fans] zero copy & 9p (was Re: PDP11 (Was: Re: what heavy negativity!)

rom others. > >>> But some experiments in nix and in a thing I wrote for leanxcale show > >>> that > >>> some things can be much faster. > >>> It’s fun either way. > >>> > >>>> El 13 oct 2018, a las 23:11, hiro <23h...@

Re: [9fans] zero copy & 9p (was Re: PDP11 (Was: Re: what heavy negativity!)

They are machines designed to run programs most people do not write! On Mon, 15 Oct 2018 at 19:20, hiro <23h...@gmail.com> wrote: > > Also, NUMA effects are more important in practice on big multicores. Some > > of the off-chip delays are brutal. > > yeah, we've been talking about this on #cat-v.

Re: [9fans] zero copy & 9p (was Re: PDP11 (Was: Re: what heavy negativity!)

> I'll see if I wrote up some of it. I think there were manual pages for the >> Messages replacing Blocks. > > Here are the three manual pages https://goo.gl/Qykprf It's not obvious from them, but internally a Fragment can represent a slice of a Segment*

Re: [9fans] Plan 9 C compiler for RISC-V by Richard Miller

He wants something I think that generates code that will run on unixy systems, and there isn't one, except in specialised ways. On Sun, 28 Oct 2018 at 14:20, Skip Tavakkolian wrote: > Inferno sources include kencc that build on the target os/arch. > > On Sun, Oct 28, 2018, 5:41 AM wrote: > >> R

Re: [9fans] Plan 9 C compiler for RISC-V by Richard Miller

It's z because the Atmel AVR is the last thing you'd want to use. (As usual, once you've got C going, it's ok, except for the design bugs.) They were in the Berkeley mote, which we worked on years ago, later on custom hardware, but always with completely different software from Berkeley's. I had li

Re: [9fans] Plan 9 C compiler for RISC-V by Richard Miller

, 6l amd64 .7 7a, 7c, 7l arm64 .8 8a, 8c, 8l 386 .9 p9p, 9[acl] power64 On Tue, 30 Oct 2018 at 09:35, Anthony Martin wrote: > Charles Forsyth once said: > > I had a chart somewhere with the available non-unicode letters. > > I made one a few years ago. It's at http://pbrane

Re: [9fans] Plan 9 C compiler for RISC-V by Richard Miller

I used Ka/Kb/Kc (upper case) for my Fairchild Clipper port, but that doesn't work on case-insensitive file systems. I did once make the changes for unicode, but again there can be problems with non-Plan9 file systems, even now. On Tue, 30 Oct 2018 at 12:43, Ethan Gardener wrote: > On Tue, Oct

Re: [9fans] Plan 9 C compiler for RISC-V by Richard Miller

I was the one that replaced Alpha by ARM64 as 7 for Plan 9. On Wed, 31 Oct 2018 at 13:44, Ethan Gardener wrote: > On Tue, Oct 30, 2018, at 3:37 PM, Steve Simon wrote: > > > > There once was a vax port but i don’t know what its letter was. > > Well, 7 used to be Alpha. I remember someone being v

Re: [9fans] Plan 9 64-bit?

I still run a version of that kernel on my cpu servers and some other devices. There might be some changes I've made that I haven't pushed yet. Unfortunately, I haven't had much time for systems work for a good year or more, so I haven't merged in changes made elsewhere. On Wed, 30 Jan 2019 at 09

Re: [9fans] microsoft's plan 9 distribution

well spotted On Sat, 16 Feb 2019 at 00:48, hiro <23h...@gmail.com> wrote: > > https://blogs.msdn.microsoft.com/commandline/2019/02/15/whats-new-for-wsl-in-windows-10-version-1903/ > >

Re: [9fans] microsoft's plan 9 distribution

I thought I remembered the name Brian Perkins until I realised that was a Radio 4 newsreader. On Sat, 16 Feb 2019 at 08:54, Steve Simon wrote: > interesting... > > the first thing, can you convince the 9p server to offer 9p over tcp? > then, can explorer mount my plan9 file server? > > the bigge

Re: [9fans] Don't Plan 9 C compiler initialize the rest of member of a struct?

Yes, that's normal C behaviour. Only external and static storage is guaranteed to be zero. In a modern environment it seems a little mean, especially since you gave opt a partial initial value, but there are no half-measures in C. On Tue, 2 Apr 2019 at 01:27, Jeremy O'Brien wrote: > On Mon, Apr

Re: [9fans] Don't Plan 9 C compiler initialize the rest of member of a?struct?

> > In the present case, this appears to be a compiler bug. The aforementioned > reference to n1548 sec 6.7.9 para 10 is incorrect in that there _is_ an > explicit initializer here. The relevant text in the standard is sec 6.7.9 > pp 16-21, which specifies that in the event that an explicit initial

Re: [9fans] Don't Plan 9 C compiler initialize the rest of member of a struct?

> What is "be initialized implicitly the same as objects that have > static storage duration" mean? It refers back to the second part of case 10 of that section. On Tue, 2 Apr 2019 at 15:53, Kyohei Kadota wrote: > Thank you for a reply. > > I read spec on http://www.open-std.org/jtc1/sc22/WG14

Re: [9fans] Don't Plan 9 C compiler initialize the rest of member of a?struct?

covered and covered1 On Tue, 2 Apr 2019 at 17:26, Anthony Martin wrote: > Charles Forsyth once said: > > I didn't look at the code closely enough earlier, but remembered > something > > from years ago this morning. It's a bug. It isn't platform specific. >

Re: [9fans] Don't Plan 9 C compiler initialize the rest of member of a struct?

yes, how true. On Tue, 2 Apr 2019 at 18:22, Devon H. O'Dell wrote: > Also worth noting that any padding bits are zeroed as well for > aggregate and union types. Not just setting all pointer values to NULL > and arithmetic types to positive or unsigned zero. > > Op di 2 apr. 2019 om 08:17 schreef

Re: [9fans] POSIX shared memory (shm_open)

There's some support for sharing memory segments in segattach(2) and between unrelated processes with segment(3). On Wed, 24 Apr 2019 at 16:23, Lassi Kortela wrote: > Hello, > > Can the POSIX shared memory API be emulated on Plan 9 with reasonable > effort? I didn't find any mention of 'shm_open

Re: [9fans] linux 9p: uid & gid

4294967294 probably started off as -2, which some systems used for user "nobody" On Thu, Jun 20, 2019 at 4:04 PM Oleg wrote: > Hi, all. > > I wrote a 9p fs with help of libixp and after mounting i see strange uid > and > gid numbers for files: > > ~# mount -t 9p -o trans=unix,noextend q t > ~# l

Re: [9fans] thoughs about venti+fossil

> The statistician replies that while the odds of being on a plane with > _one_ bomb are too high for him, the odds of being on a plane with > _multiple_ bombs are infinitesimal. probably that explains why Homeland Security always seemed to be on Orange Alert. at first i thought it had somethin

Re: [9fans] thoughs about venti+fossil

> And if one day you do get a collision, > venti will tell you and then you can tell your grandchildren

Re: [9fans] Are acme-sac questions ok here?

There's an Inferno for the discussion of all aspects of Inferno and Limbo (which would include acme-sac because it's built on that). To subscribe to that list, send a message to [EMAIL PROTECTED], including the word "subscribe" in the subject or body of the message. There is, however, acme-sac sp

Re: [9fans] ARMv6 compiler ? (was: more bitsy stuff)

>is it possible to (cross-)compile plan9 sources on Linux ? i did that for Solaris years ago. the compilers are the easy bit; you also need to modify mkfiles to add a root variable. (it was 8 years ago and i can't remember many details.) for Linux, now, you're probably better off if you can get

Re: [9fans] acme/sam linewrapping off

> Well, [EMAIL PROTECTED] could definitely be a choice. But, doesn't it go > against the > basic philosophy ... ??! the response here usually follows these steps: (1) at most a mild suggestion to try using the system somewhat as intended (2) ignoring it this is in contrast to affirmative-action

Re: [9fans] Does sam accepts interrupt signal

it has been some time since i last used sam interactively, but your description sam appears to forget the state (in fact it's I that forget it) and treat my input as plain text. In this case, no matter putting a single dot or completing with a `/' could not save me. As a r

Re: [9fans] getcallerpc on arm7

>It appears that 5c (the ARM compiler) saves the return PC >as the first word of the stack frame, which may be somewhat >hard to locate. it should be the same as the other risc machines, and seems all right when i test it with 5c/5l. gcc typically also uses a frame pointer, which might make it ne

Re: [9fans] hot or not

> Or does your Plan 9 go to 10? we always turn it up to 11.

Re: [9fans] funny spam

> ladd Apr 6 13:38:27 Hung up on 62.31.39.89; claimed to be happy indeed. they just wouldn't fit in here.

Re: [9fans] FTQ benchmark available

> Ron just handed me a tarball one day and said, "Thou Shalt Port This", > so I did. I'll look at the one on sourceforge. i wonder if they'll give the same results!

Re: [9fans] FTQ benchmark available

> Seriously: what's the point? i'm sometimes interested in seeing the differences (if any) caused by certain system changes, with a view to showing that you can be fast but still straightforward and sane, without a load of ugly code let alone inlined assembly code and 60,000 lines of include files

Re: [9fans] telnet vs. godaddy whois

> Plan 9 ignores the zero length window and sends a single byte (2456ms), > causing godaddy to hang up (2493ms). it is probing the zero window (rfc793, section 3.7)

Re: [9fans] telnet vs. godaddy whois

> Er... "correct" seems a bit strong. Why is Plan9 sending one > byte of data when it knows the receiver's window is closed? read the section of the rfc i mentioned earlier. it probably ought to probe only after a retransmission timeout period, but that's not a predetermined value, and can be sh

Re: [9fans] Plan 9 refuses to boot from iMac

> OS X EFI emulates a BIOS. That's how Boot Camp works. this stuff gets worse and worse, doesn't it.

Re: [9fans] telnet vs. godaddy whois

> The transmitting host SHOULD send the first zero-window > probe when a zero window has existed for the retransmission > timeout period (see Section 4.2.2.15), and SHOULD increase > exponentially the interval between successive probes. that first part requires an action in a given case, to en

Re: [9fans] telnet vs. godaddy whois

> having said that, i now suspect that sending one byte into a zero-window is > not the problem. because the one-byte probe can only be done if there is data to send, and i already knew that a plain connection (dial only) to that port also failed: 014045 ms ether(s=000e2e32f2a6 d=00a0c

Re: [9fans] telnet vs. godaddy whois

> I noticed this some time ago when I was doing some work in the > stack and thought it was very questionable. But I never got a > chance to go back and do further research. Nevertheless I think > it's the wrong behavior. what's the definition of `wrong' here?

Re: [9fans] telnet vs. godaddy whois

> Because of this what is likely happening is that on receiving > the PSH bit read() completes and returns to the caller app > with a count = 0 which the app must think indicates EOF! that behaviour (by the remote) is correct?

Re: [9fans] telnet vs. godaddy whois

> what's the definition of `wrong' here? > Meaning that the patch Eric proposed is probably the better way to > deal with ACKs. It wasn't meant to be taken too literally though, > hence the "I think". what's the definition of `better' here? well, i won't persist in pedantry. i was ju

Re: [9fans] telnet vs. godaddy whois

FreeBSD 5.0-CURRENT (which is old, but one i've got) didn't work with echo | telnet godaddy either, although i haven't traced that yet. it's the same on my powerpc mac, though. there's another tcp subtlety that could cause that though, assuming it's not just telnet getting in the way.

Re: [9fans] telnet vs. godaddy whois

> if we've sent an illegal packet, can we say any behaviour on > the remote end is incorrect? that packet is by no means `illegal'.

Re: [9fans] telnet vs. godaddy whois

> rfc 742 p. 42 says > > [...] If the the user signals a push function then the > data must be sent even if it is a small segment. > > by "illegal" i mean goes contrary to an rfc "must." perhaps > i'm missing something. i don't see how what was sent is contrary to that requirement.

Re: [9fans] telnet vs. godaddy whois

to be fair, this is one reason a few programming languages have non-trivial validation suites, much of which check probable or historical misunderstandings, and those suites are usually too small. it takes a fair amount of back-and-forth through the natural language text to build a supposedly co

Re: [9fans] telnet vs. godaddy whois

> Has anybody ever experienced this problem > before with any of there P9 systems? I haven't. not this particular problem, but years ago i had problems with plan 9 or perhaps it was inferno (originally) not implementing the window test correctly (leading to a RST storm with an incorrect AIX

Re: [9fans] telnet vs. godaddy whois

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!

Re: [9fans] telnet vs. godaddy whois

> 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: [9fans] telnet vs. godaddy whois

> 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.

Re: [9fans] telnet vs. godaddy whois

> 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

Re: [9fans] telnet vs. godaddy whois

> 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

Re: [9fans] telnet vs. godaddy whois

> 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

Re: [9fans] telnet vs. godaddy whois

> 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

Re: [9fans] telnet vs. godaddy whois

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

Re: [9fans] /lib/rfc

> Perhaps we > were lucky and did not connect to a broken router again. >The fault on why QEMU crashes every time > I boot Plan 9 -- venti. With a fossil only system, everything worked > without a hitch -- until that corrupt >On Leopard I've found that QEMU runs very slowly but crashes >exc

Re: [9fans] LSI Logic 53C1030 SCSI

> the payoff of getting a couple of old, slow, small drives > going isn't quite there for me. (actually i have two chassis with > hot-swappable raid backplanes and 18gb drives.) you should get better > performance out of a $50 ata hard drive these days. recently i decided to archive a dozen or so

Re: [9fans] ftpfs ahould not expose "." and ".." directories

just for completeness, in plan 9 code it also would be if(strcmp(".", field[8]) == 0 ...) etc. not `!strcmp', and indeed it is that way elsewhere in ip/ftpfs.c similarly, it is usually if(p != nil) ... not if(!p) there are other guidelines in style(6)

Re: [9fans] ftpfs ahould not expose "." and ".." directories

> similarly, it is usually > if(p != nil) > ... > not > if(!p) ha ha. sorry i meant if(p == nil) not if(!p)

Re: [9fans] LSI Logic 53C1030 SCSI

> How old are those drives? > My very vague rule of thumb is that the bathtub failure curve for most > moving computer machinery > rises steeply after at most about 5 years, > so if they're already a few years old ... they varied: typically 7 or 8, some 10 to 15

Re: [9fans] Disassembler?

i normally give the -a option to 8l(1)

Re: [9fans] Disassembler?

> i normally give the -a option to 8l(1) or use db(1) or acid(1)

Re: [9fans] MOVBLSX

move byte to long with sign extension

<    1   2   3   4   5   6   7   8   9   10   >