Re: [9fans] cpu command latency

[Kenny Lasse Hoff Levinsen]

Well, based on the 9fs test that was posted, I'd think dial is being awfully 
slow.

Maybe try something simpler? aux/listen1 echo hello and a simple network 
connection?

Best regards,
Kenny Levinsen

> On 11. maj 2016, at 16.13, Charles Forsyth <charles.fors...@gmail.com> wrote:
> 
> 
>> On 11 May 2016 at 14:44, Kenny Lasse Hoff Levinsen <kennylevin...@gmail.com> 
>> wrote:
>> Delete the channel from /srv in the loop to test a full remote mount dance, 
>> including the initial dial. It shouldn't take 3s to dial, though.
> 
> There's something initially slow in connecting to  grid.nyx.link with cpu, 
> and setting up, but once there it's fine.

Re: [9fans] cpu command latency

[Kenny Lasse Hoff Levinsen]

Your loop only seems to dials the server once, then reuses the channel from 
/srv. 9fs(4) is just a convenience wrapper for common hosts and tasks that 
ultimately calls srv(4) and mount(1) as necessary - if the channel exists, it 
is simply a call to mount(1), which translates to an attach(5) 9P message on 
the existing connection.

Delete the channel from /srv in the loop to test a full remote mount dance, 
including the initial dial. It shouldn't take 3s to dial, though.

Best regards,
Kenny Levinsen

> On 11. maj 2016, at 15.12, arisawa  wrote:
> 
> thanks charles for your quick response.
> 
> the times below are mount latency just after rebooting.
> the first is much larger than others.
> 0.00u 0.00s 3.73r 9fs sources
> 0.00u 0.00s 0.71r 9fs sources
> 0.00u 0.00s 0.21r 9fs sources
> with the script below:
> for(i in 1 2 3){
>time 9fs $host
>unmount /n/$host
>sleep 3
>}
> }
> 
> probably cpu command latency will show similar behavior with much more time.
> 
> Kenji Arisawa
> 
> 

Re: [9fans] Go on Plan 9?

[Kenny Lasse Hoff Levinsen]

I tried that at some point. Got pi2 booting with one core, crashed with 
multiple, but then again, I'm new to having to be that intimate with assembly 
and kernel mode.

I'd suggest trying from scratch to port things, but there are a few 9front 
differences that make it much more than just a diff.

Best regards,
Kenny Levinsen

> On 13. apr. 2016, at 16.00, Chris McGee  wrote:
> 
> Ah, that makes sense. It’s virtual memory and not the physical memory.
> 
> Do you think that your changes to the bcm will make it to 9front? If not, any 
> chance I could have the diffs so that I can try merging them in there myself?
> 
> Thanks,
> Chris

Re: [9fans] Fwd: Multiplexing Styx/9P2000 over TCP connections

[Kenny Lasse Hoff Levinsen]

On plan9, you use srv to add the connection as a file to /srv, then mount the 
file. Mount does not make TCP connections (although srv can call mount for you 
as a convenience feature).

Multiplexing requires ensuring that tag and fid collisions do not occur, either 
with coordination or translation tables. I do not believe that the kernel needs 
this multiplex, as it seems like an uncommon scenario. Why would you mount the 
same fs twice on the same machine? Also, as you mentioned, a userspace process 
could handle this easily of needed.

Best regards,
Kenny Levinsen

> On 3. mar. 2016, at 03.09, cigar562hfsp952f...@icebubble.org wrote:
> 
> I recently posted the following to the Inferno mailing list (but
> received no response).  I'm re-posting here, as this applies to Plan 9
> just as much as to Inferno, anyway...
> 
>> So, I've been looking at the source code of Inferno, and I've noticed
>> that, when mount(1) wants to connect to a Styx/9P2000 server on a remote
>> machine, it generally opens up a new TCP connection... one for each new
>> mount... even if it's just an additional connection to the same service
>> on the same remote host.
>> 
>> Recalling the specification for 9P2000, the protocol supports the
>> multiplexing of multiple 9P2000 clients/"sessions" onto a single,
>> multiplexed, session with the server.  In theory, all a 9P2000
>> multiplexer would have to do is map tags and fids so that different
>> clients don't use the same values, and negotiate a common version and
>> msize in the Tversion/Rversion transactions.  All the functionality of
>> the protocol, including access control using afids, would be preserved.
>> In fact, while complying fully with the 9P2000 specification, it should
>> also be possible to multiplex sessions in the REVERSE direction
>> (connections from clients on the remote "server" host BACK to servers
>> listening on the local "client" host) over the same TCP connection used
>> to carry the "forward" (local --> remote) sessions.
>> 
>> I'd assumed, since the protocol allows for this, that this sort of
>> multiplexing was done by the Plan 9 and Inferno kernels.  Is that not
>> the case?  And if not, then why not?
>> 
>> To take a stab at answering my own question, I suspect that it might
>> have something to do with the Station to Station protocol and SSL setup
>> done on a connection prior to exchanging Styx messages.  But it seems to
>> me that S2S and SSL init could also be multiplexed by the kernel, or
>> even transacted over a temporary TCP connection established solely for
>> initializing the Styx session.  That is to suggest that a client could
>> connect directly to a server, execute S2S, close that connection,
>> provide the SSL parameters and shared secret to the kernel, then push
>> the Styx messages (including any afid) through the kernel multiplexer.
>> The kernel could then send the client's Styx messages over the
>> multiplexed connection using the SSL parameters specified by the client.
>> 
>> I'd imagine that there could be some latencey issues that might result
>> from an approach like this, i.e. if an interactive session were
>> conducted over the same connection as a large file transfer.  But
>> there's nothing to stop a client from establishing its own TCP
>> connection (or, at the very least, asking the kernel to allocate a
>> second multiplexed connection).  Still, multiplexing Styx sessions could
>> have some advantages, such as when traversing firewalls where there are
>> limits on the number of simultaneous TCP connections or timeouts on
>> individual connections.  Multiplexing sessions would help "keep alive"
>> such TCP connections.  It would also help protect encrypted
>> communication from traffic analysis.
>> 
>> Now that I've been typing about this for a few paragraphs, it occurs to
>> me that a multiplexer like this could probably be implemented as a
>> system service running in userspace, without much (if any) extra support
>> from the kernel.
>> 
>> So, do Plan 9 or Inferno already do anything like this?  If not, do you
>> think it would be a smart thing to implement?  I'm curious to hear other
>> people's thoughts on this.
> 

Re: [9fans] Go: FP in note handler

[Kenny Lasse Hoff Levinsen]

> On 23 Feb 2016, at 18:31, lu...@proxima.alt.za wrote:
> 
>> A proper duffcopy/duffzero/memmove is also an option.
> 
> The adjective "proper" is revealing.  I vote for that.
> 
> Lucio.
> 
> 

It’s a bit out of my usual area of expertise, however. I have no idea what 
benchmark they have been running, either. Any pointers?

Kenny

Re: [9fans] rtl8169 gbe slow

[Kenny Lasse Hoff Levinsen]

Just in case you want a another point of reference to eliminate weirdness with 
the specific box: http://de.kl.wtf/f/10mburandom

Linode Arch Linux box in Frankfurt, serving you with a pretty standard usage of 
Go’s http server. Should count as a “stock linux box with a non-weird HTTP 
server”.

if you add an “s”, you get TLS. If you add a “0”, you get 100MB. If you remove 
a country code, it goes through Cloudflare. You’ll have to guess where to 
insert and remove those characters yourself, though!

Best regards,
Kenny Levinsen

> On 23 Feb 2016, at 18:38, erik quanstrom  wrote:
> 
> On Tue Feb 23 09:25:53 PST 2016, 23h...@gmail.com wrote:
>> in the long run the rwin seems much higher (65535) than the number of
>> bytes in flight (less than 3x1500 bytes).
>> 
>> i just noticed that the minimum latency numbers seem way low. many
>> latency samples appear at around 40ms and 100ms, but there's also
>> outliers? below 1ms. i don't get how this pcap got produced. perhaps
>> wireshark is also interpreting it wrong, or timestamps are broken...
> 
>>> 26/status:Established qin 0 qout 0 rq 0.0 srtt 1256 mdev 628 sst 65535 cwin
>>> 4517 swin 5808>>0 rwin 65535>>4 qscale 0 timer.start 10 timer.count 10
>>> rerecv 0 katimer.start 2400 katimer.count 2400
>> 
>> where did you run this?
> 
> machine on the us west coast.  clearly we are prevoking some sort of odd 
> behavior
> in this machine, but it's not clear to me what we're doing.
> 
> the only clue we have is the out-of-window rxes.  perhaps the sender is 
> scaling.
> 
> - erik
> 

Re: [9fans] Go: FP in note handler

[Kenny Lasse Hoff Levinsen]

A proper duffcopy/duffzero/memmove is also an option.

Best regards,
Kenny Levinsen

> On 23. feb. 2016, at 18.02, erik quanstrom  wrote:
> 
>> On Tue Feb 23 07:55:26 PST 2016, kennylevin...@gmail.com wrote:
>> A benchmark was supposedly made of the new duffcopy/duffzero which claimed 
>> significant speedup for larger copies: 
>> https://github.com/golang/go/commit/5cf281a9b791f0f10efd1574934cbb19ea1b33da
>> 
>> I have no clue whether this holds true or not. My intention to reenable 
>> duffcopy and continue to use duffzero is mostly to avoid differences and 
>> ensure that the note handlers are floating point free in the future. Whether 
>> the duffcopy/duffzero’s current form is an actual optimization or just a 
>> complexity, I cannot say. A test was made in #cat-v out of annoyance where 
>> the result seemed to be that it was indeed faster to use MOVUPS, but I don’t 
>> remember the details.
> 
> that post is a speedup relative to the original asm, which might not be as 
> good as the best
> non-sse versions, and it is also for amd64.
> 
> - erik
> 

Re: [9fans] Go: FP in note handler

[Kenny Lasse Hoff Levinsen]

A benchmark was supposedly made of the new duffcopy/duffzero which claimed 
significant speedup for larger copies: 
https://github.com/golang/go/commit/5cf281a9b791f0f10efd1574934cbb19ea1b33da

I have no clue whether this holds true or not. My intention to reenable 
duffcopy and continue to use duffzero is mostly to avoid differences and ensure 
that the note handlers are floating point free in the future. Whether the 
duffcopy/duffzero’s current form is an actual optimization or just a 
complexity, I cannot say. A test was made in #cat-v out of annoyance where the 
result seemed to be that it was indeed faster to use MOVUPS, but I don’t 
remember the details.

Best regards,
Kenny Levinsen

> On 23 Feb 2016, at 16:27, erik quanstrom  wrote:
> 
> On Tue Feb 23 02:36:41 PST 2016, kennylevin...@gmail.com wrote:
>> Ah, no - it is not a system-wide adjustment, but adjustment of the plan9 
>> specific runtime.sighandler implementation and everything called by it 
>> directly. Notes that don't exit the process are queued and should run 
>> outside the actual note handler.
>> 
>> I think the "magic" code will be isolated, and might fend off accidental 
>> future additions of floating point registers. The magic-ness also only 
>> revolves around avoiding duffzero and duffcopy in some way. I also think 
>> that removing conditionals in the compiler will be a positive thing.
>> 
>> I still do not know the feasibility of my plan, whether it is possible to do 
>> cleanly, or possible at all. Maybe someone smarter than me with knowledge on 
>> the matter could chime in and call me an idiot?
>> 
>> Avoiding duffcopy should be easy with a simple memmove implementation. If 
>> done right, we can also remove the plan9 specific runtime.memmove and only 
>> use the slow memmove in sighandler (The globlal runtime.memmove is 
>> implemented using MOVUPS just like duffcopy. Duffcopy is used for 
>> blockcopies by the compiler in some cases, although I must admit to not know 
>> all the cases yet).
>> 
>> Avoiding duffzero without compiler assistance is a bit more tricky - global 
>> variables, stack on assembly functions, something like that.
> 
> fwiw, on modern amd64 machines, using the xmm and ymm registers has a benefit 
> only in a narrow range
> of sizes (384-511 bytes) and a subset of (mis-)alignments that i've 
> forgotten.  at least for the exact test setup
> i used on 3-4 different µarches.  intel claims rep; movs is the 
> (architecturally) fastest way to go.
> 
> i am not sure any of this makes much difference, as it's hard to know what a 
> real-world memory
> access pattern looks like, and that seems to dominate all but gigantic moves, 
> for which rep; movs
> is actually no slower than even the trickiest use of ymm registers.
> 
> - erik
> 

Re: [9fans] Go: FP in note handler

[Kenny Lasse Hoff Levinsen]

Ah, no - it is not a system-wide adjustment, but adjustment of the plan9 
specific runtime.sighandler implementation and everything called by it 
directly. Notes that don't exit the process are queued and should run outside 
the actual note handler.

I think the "magic" code will be isolated, and might fend off accidental future 
additions of floating point registers. The magic-ness also only revolves around 
avoiding duffzero and duffcopy in some way. I also think that removing 
conditionals in the compiler will be a positive thing.

I still do not know the feasibility of my plan, whether it is possible to do 
cleanly, or possible at all. Maybe someone smarter than me with knowledge on 
the matter could chime in and call me an idiot?

Avoiding duffcopy should be easy with a simple memmove implementation. If done 
right, we can also remove the plan9 specific runtime.memmove and only use the 
slow memmove in sighandler (The globlal runtime.memmove is implemented using 
MOVUPS just like duffcopy. Duffcopy is used for blockcopies by the compiler in 
some cases, although I must admit to not know all the cases yet).

Avoiding duffzero without compiler assistance is a bit more tricky - global 
variables, stack on assembly functions, something like that.

Best regards,
Kenny Levinsen

On 23. feb. 2016, at 10.05, lu...@proxima.alt.za wrote:

>> Well, avoiding XMM registers in duffcopy/duffzero is one solution, but
>> I was thinking of working around them entirely in code called from the
>> note handler, so that duffcopy/duffzero can operate as intended on
>> plan9, rather than littering the compiler with OS conditionals.
> 
> Do you think you'll be able to sell that to the Go developers?  You
> ARE talking about a system-wide adjustment and it seems to me that it
> will need constant supervision to be maintained.  Again, I may have
> misunderstood, but it does seem like a maintenance nightmare to me.
> 
> As for:
> 
>> To fix the duffzero, we'd have to fix runtime.goexitsall's buffer
>> usage, but to reenable duffcopy, we'd have to look at the much bigger
>> runtime.sighandler.
> 
> That is undeniable, but to avoid a different type of maintenance
> nightmare, may be the only option.  Although "fixing" duffcopy and
> duffzero would seem a better, if less efficient option.
> 
> Still, it's the opinion of a none-too-well-informed spectator, do not
> let me spoil it for you.  In particular, I'm sure I'm not telling you
> anything you have not already considered.
> 
> Lucio.
> 
> PS: I do think that it is our responsibility to track each and every
> aspect of Go where Plan 9 demands special treatment.  Ideally, this
> means build flags or specially named modules and a commitment from a
> few of us to keep these in sync.  Anything else becomes someone else's
> responsibility and that is risky.
> 

Re: [9fans] Go: FP in note handler

[Kenny Lasse Hoff Levinsen]

Well, avoiding XMM registers in duffcopy/duffzero is one solution, but I was 
thinking of working around them entirely in code called from the note handler, 
so that duffcopy/duffzero can operate as intended on plan9, rather than 
littering the compiler with OS conditionals.

It puts some restrictions on the note handling code, such as no copy(), make() 
or even an on-stack var b [n]byte. Due to sighandler disabling write barriers, 
we can't currently allocate on the heap, meaning that we might need either 
locked global buffers (which can be duffzeroed) or more assembly so we can use 
on-stack buffers (which could be zeroed if we wanted to, they just can't use 
duffzero for it).

To fix the duffzero, we'd have to fix runtime.goexitsall's buffer usage, but to 
reenable duffcopy, we'd have to look at the much bigger runtime.sighandler.

Best regards,
Kenny Levinsen

On 23. feb. 2016, at 08.20, lu...@proxima.alt.za wrote:

>> Duffcopy is disabled from plan9 after the last bug report on the
>> matter, but duffzero was later optimized to use XMM registers, causing
>> goexitsall, which use an on-stack byte array to make a new note, to
>> call duffzero and trip the fp in note handler message.
> 
> I had to re-read this to understand this because you tend to put at
> the end what I would find easier to understand if it was at the
> beginning.  No offence meant, different punctuation would have perhaps
> helped my understanding.
> 
> So, we need a duffcopy and duffzero that do not use XMM registers,
> rather than stop invoking them, if I read your comment correctly?
> 
> I also have an open issue (I see David has offered to look into it
> soon) involving syscalls and their error messages, it seems these are
> all Plan 9 specific issues that could be addressed together.
> 
> I really would like to take a more active role in Go for Plan 9, but I
> can't yet give it the priority I'd like.  Still, I like hearing from
> others who take this to heart.
> 
> Lucio.
> 

[9fans] Go: FP in note handler

[Kenny Lasse Hoff Levinsen]

For those interested in the matter, I have opened 
https://github.com/golang/go/issues/14471

I mention potentially reenabling duffcopy by writing some magic note handler 
code that avoid the regular copy and zero optimizations, but I’m not entirely 
sure if that’s a plausible path. If it is, I think it would bring benefit, both 
in the performance gained by duffcopy/duffzero, as well as the chances of this 
happening again. It is, however, slightly annoying to do, as you cannot use 
copy(), make() or even strings or byte array literals, as these will trip 
duffcopy and duffzero. Any comments to my silly idea?

Best regards,
Kenny Levinsen

> On 22 Feb 2016, at 18:16, Richard Miller  wrote:
> 
>> The trace of goexitsall still contain FP register access (XORPS and duffzero 
>> which contains MOVUPS)
> 
> Sorry, in that case I think my patch is not relevant for your issue
> (but it does prevent a deadlock on multiprocessors which you might
> also run into...)
> 

Re: [9fans] rtl8169 gbe slow

[Kenny Lasse Hoff Levinsen]

Lucio: Of course I'll make an issue, I only just noticed it and traced it to 
goexitsall. Don't worry. :)

Richard: Thanks, I'll try that. The trace of goexitsall still contain FP 
register access (XORPS and duffzero which contains MOVUPS), but maybe that 
doesn't matter if the race is fixed?

I didn't intend to hijack the thread, just pointed out that it is indeed not 
hget or webfs at fault.

Best regards,
Kenny Levinsen

On 22. feb. 2016, at 17.40, lu...@proxima.alt.za wrote:

>> Fun sidenote: more floating point code in note handlers, this time 
>> duffzero when calling os.Exit. *sigh*.
> 
> Can you please submit it as an issue, so we at least know it's there?
> 
> Lucio.
> 
> 

Re: [9fans] rtl8169 gbe slow

[Kenny Lasse Hoff Levinsen]

Go http client + go http server on a vps (14.2ms ping) show same issues: 182s 
to download 100MB from remote using a 9front VM, 7s local, vs. 30s and 1s for 
the linux host.

So yeah, hget/webfs has nothing to do with it.

Fun sidenote: more floating point code in note handlers, this time duffzero 
when calling os.Exit. *sigh*.

Best regards,
Kenny Levinsen

On 22. feb. 2016, at 16.46, David du Colombier <0in...@gmail.com> wrote:

>> No. Is it possible to change the string for hget?
> 
> You can change the string in /sys/src/cmd/hget.c.
> But this issue is not related to hget, since it doesn't happen when
> using hget on Linux or 9vx.
> 
> It seems related to the Plan 9 TCP stack, or how the network
> infrastructure behaves with it.
> 
> -- 
> David du Colombier
> 

Re: [9fans] rtl8169 gbe slow

[Kenny Lasse Hoff Levinsen]

Is your MTU higher that 1500? That might be able to mess things up over the 
internet.

Best regards,
Kenny Levinsen

> On 20. feb. 2016, at 11.32, tlaro...@polynum.com wrote:
> 
> I have compared downloading a file (via ftpfs) on the LAN, and
> downloading it from the WAN.
> 
> On the LAN, I get the 10MB file in less than a 1s (this is normal since
> the node I download from has only a 100Mb ethernet).
> 
> On the WAN, it takes 6 minutes (with hget).
> 
> My conclusion is that the card device (driver) is not at fault but that
> something is wrong along the path when I get through the gateway.
> 
> Has somebody an idea about what I may do wrong or what could cause such
> a cost on the gateway.
> 
> I have set IPv6 on the gateway: no difference. I have tried to disable
> IPv6 on the ether: no difference. 
> 
> ip/traceroute to the outside server shows results that are on par
> with what I get from NetBSD on this very node where I run also
> plan9.
> 
> "Something" is obviously wrong. But "what" is less obvious (at least to
> me).
> 
> -- 
>Thierry Laronde 
> http://www.kergis.com/
> http://www.arts-po.fr/
> Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C
> 

Re: [9fans] plan9port for El Capitan(10.11.3)

[Kenny Lasse Hoff Levinsen]

As for drawterm-cocoa: Sure you're using the newest version? Sounds like the 
old one, which was very broken indeed. There are known refresh-issues even in 
the current one, like immediately after starting rio, of when returning to the 
console.

Best regards,
Kenny Levinsen

> On 19. feb. 2016, at 14.27, kokam...@hera.eonet.ne.jp wrote:
> 
> I'm using p9p on MacOS 10.11.3, and having a strange behaviour.
> I have to resize the 9term (or any other) window to show its contents.
> 
> In the case of drawterm(Jas's cocoa version), I have no prompt 
> before I type the keyboard.
> In this case resizing the window doesn't help.
> 
> Are these behaiviours expected ones?
> 
> Kenji
> 
> 

Re: [9fans] NetSurf (browser) and Duktape (javascript)

[Kenny Lasse Hoff Levinsen]

I am aware, I work with web, but no JS will work before the DOM implementation 
is complete, and most is utterly useless without styling. It's a better place 
to start. One can also work without JS for a lot of pages that aren't twitter 
bootstrap based, or fetching content dynamically. The first is an issue, but 
the latter not that much... Yet.

Best regards,
Kenny Levinsen

> On 19. feb. 2016, at 14.21, tlaro...@polynum.com wrote:
> 
>> On Fri, Feb 19, 2016 at 02:00:47PM +0100, Kenny Lasse Hoff Levinsen wrote:
>> Styling/proper rendering might be more interesting than JS.
> 
> Unfortunately, today, there are a number of sites that require
> javascript. I don't speak about overloaded media sites. But for example
> bank or even governemental sites.
> 
> It is unfortunate to have, for some common tasks, the need of
> "something else" (and due to the size and complexity of Mozilla
> and Chrome, "something else" can be a pretty restrictive choice).
> 
> If I'm not mistaken, Russ Cox says somewhere that he was happy working
> under Plan9 but that he ported the Plan9 utilities to other systems when
> he realized there was no hope that someday Mozilla will run on Plan9...
> So he still uses Plan9 utilities, but not under Plan9...
> -- 
>Thierry Laronde 
> http://www.kergis.com/
> http://www.arts-po.fr/
> Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C
> 

Re: [9fans] NetSurf (browser) and Duktape (javascript)

[Kenny Lasse Hoff Levinsen]

Styling/proper rendering might be more interesting than JS.

Best regards,
Kenny Levinsen

> On 19. feb. 2016, at 13.22, tlaro...@polynum.com wrote:
> 
>> On Fri, Feb 19, 2016 at 01:17:12AM +0100, Aram H?v?rneanu wrote:
>> What problem would this solve, it's not like netsurf can display any
>> useful web page that mothra can't display.
> 
> NetSurf will incorporate Duktape javascript engine. Does Mothra have
> javascript?
> 
> -- 
>Thierry Laronde 
> http://www.kergis.com/
> http://www.arts-po.fr/
> Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C
> 

Re: [9fans] Go on Plan 9?

[Kenny Lasse Hoff Levinsen]

Go builds just fine right now on the plan9 builders: http://build.golang.org

1.4 and 1.5 are very different, due to 1.5 being written in Go. i386 and amd64 
should both build, although amd64 fails an irrelevant unittest.

What do you see with 1.5.2/1.5.3? (You said you tried?)

Best regards,
Kenny Levinsen // joushou

> On 26 Jan 2016, at 22:52, s...@9front.org wrote:
> 
> From http://fqa.9front.org/appendixl.html:
> 
>   # automatically converted ca certs from mozilla.org
>   hget http://curl.haxx.se/ca/cacert.pem >/sys/lib/tls/ca.pem
>   # shell script that emulates git commands
>   hget http://9front.org/extra/rc/git >$home/bin/rc/git
>   chmod 775 $home/bin/rc/git
>   # fetch the repository
>   git clone https://go.googlesource.com/go
>   cd go
>   git checkout go1.4.2
>   # build go
>   cd src
>   ./make.rc
>   # install documentation
>   go get golang.org/x/tools/cmd/godoc
>   # go!
> 
> Newer versions of go seem to have problems with Plan 9.
> 
> sl
> 

Re: [9fans] bug or feature ? --- ip/ping -6

[Kenny Lasse Hoff Levinsen]

It is not a common factor if you ping broadcast. That is, the local address is 
common, the remote is not.

joushou

> On 30 Dec 2015, at 20:05, Steve Simon  wrote:
> 
> I would display the IP address once only, rather on every line; as it is a 
> common factor.
> 
> -Steve
> 
> 
>> On 30 Dec 2015, at 15:26, Kurt H Maier  wrote:
>> 
>>> On Wed, Dec 30, 2015 at 03:05:33PM +, Steve Simon wrote:
>>> If I where redesigning ping I wouldn't repeat any info that is common on 
>>> each line - I.e. ip addresses or the column titles: rtt, ave etc.
>>> 
>>> consider plan9's ps(1) which has no column titles. they are described in 
>>> the man page and are obvious from the context once you have read the man 
>>> page once.
>>> 
>>> Having said this, I understand that tradition is also a strong guiding 
>>> principal.
>>> 
>>> -Steve
>> 
>> I have no opinion on the labeling, but dropping the IPs from the output
>> would make this tool useless for logging data.
>> 
>> khm
> 

Re: [9fans] using tls-psk cipher suits vs roll our own handshake

[Kenny Lasse Hoff Levinsen]

1. This could work, although if you add “if things break, try again with 
different algo”, you get 5.

2. While a good cipher, seems like something that might get us stuck in the 
future.

3. This seems a bit complicated, and is in essence 5 performed over a fixed 
cipher.

4. makes sense. I don’t think the overhead will be too bad. We get the 
Client/ServerHello/ChangeCipherSpec dance, which is of course more complicated 
than necessary, but also fairly well known, and as long as the ciphers allowed 
by the server are limited, the security concerns of this handshake should be 
minimal.

5 takes time to design properly. There’s not many attacks to protect against, 
but it should still be thought through.

I think 4 (standard tls handshake) is the safest bet, especially if we want it 
to be decently strong. We could make 5 as good and 3 better, but I don’t think 
it’s really worth the effort at the current time (and 3/5 does require effort 
if it has to be done right).

kenny // joushou

> On 24 Dec 2015, at 17:45, cinap_len...@felloff.net wrote:
> 
> plan9 currently uses the shared secret from the authentication
> process with ssl and rc4 cipher for encrypting traffic for
> exportfs and the cpu services (pushssl()). the cipher can be
> changed by the client by providing command line parameters,
> tho there is no real negotiation going on. if the server
> doesnt like the cipher from the client, the connection just
> breaks.
> 
> when switching to tls, we have a few options:
> 
> 1) do as we do with ssl, client sends what cipher and hash alg
> it wants as a string before calling pushtls().
> 
> 2) use fixed cipher like chacha20/poly1305 aead unconditionally.
> 
> 3) use fixed cipher initially, and after that, renegotiate
> cipher (devtls can change secrets and ciphers inband).
> 
> 4) use standard tls handshake with PSK cipher suits.
> 
> 5) make our own little cipher negotiation handshake protocol.
> 
> suggestions?
> 
> --
> cinap
>