Re: [9fans] broken floating point exceptions and fpregs
my terminal runs a plan 9 also with those bits. dont worry. On May 26, 2013, at 8:00 AM, lu...@proxima.alt.za wrote: >> give us a bit more time and we will put >> the new bits somewhere. > > You are back-porting this to the Bell Labs distribution, I hope? > > > ++L >
[9fans] ssh to osx
Hello, thanks to geoff and others, we can now connect to linux using ssh in official distribution from bell-labs. term% ssh -r arisawa@hebe Welcome to Ubuntu 12.04.2 LTS (GNU/Linux 3.2.0-38-generic-pae i686) * Documentation: https://help.ubuntu.com/ Last login: Sun May 26 11:00:17 2013 from maia.local hebe$ where hebe is one of my linux host. however I don't succeed yet in connecting to Mac using the ssh. term% ssh -r arisawa@mmac ssh: auth ctl msg `ssh-userauth k arisawa ' for /net/ssh/clone: ssh-userath auth failed (not Established) where mmac is mac mini that runs on osx/lion. ssh server of mmac is working as shown below. hebe$ ssh arisawa@mmac The authenticity of host 'mmac (192.168.1.7)' can't be established. RSA key fingerprint is 80:0a:fc:62:42:e1:22:5b:81:ee:2d:21:b2:bc:ee:75. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'mmac,192.168.1.7' (RSA) to the list of known hosts. Password: Last login: Thu May 23 06:55:11 2013 -bash$ I don't understand the difference of ssh server between linux and osx. any suggestion is welcome. anyone get connected to mac using ssh of Plan9? Kenji Arisawa
Re: [9fans] ssh to osx
> I don't understand the difference of ssh server between linux and osx. > any suggestion is welcome. > anyone get connected to mac using ssh of Plan9? I can't answer that. Is it possible for you to run sshd on the iMAC with debug options? That will give you at least some hints on where the problem lies. That said, there are bits of SSH 2 that still need work if I read the man pages correctly. ++L
Re: [9fans] ssh to osx
the mac only enables "keyboard interactive" auth and not "password" auth, these are very similar but different. you need to an option in a config file on the mac to enable password auth. i have done this on my mac, but to be honest i cannot remember what i did. i found it on google somewhere and i am sure you will too. perhaps you will be more through than i was and add a wiki entry when you work it out. -Steve On 26 May 2013, at 12:25, arisawa wrote: > Hello, > > thanks to geoff and others, we can now connect to linux using ssh in official > distribution from bell-labs. > > term% ssh -r arisawa@hebe > Welcome to Ubuntu 12.04.2 LTS (GNU/Linux 3.2.0-38-generic-pae i686) > > * Documentation: https://help.ubuntu.com/ > > Last login: Sun May 26 11:00:17 2013 from maia.local > hebe$ > > where hebe is one of my linux host. > > however I don't succeed yet in connecting to Mac using the ssh. > > term% ssh -r arisawa@mmac > ssh: auth ctl msg `ssh-userauth k arisawa ' for /net/ssh/clone: > ssh-userath auth failed (not Established) > > where mmac is mac mini that runs on osx/lion. > ssh server of mmac is working as shown below. > > hebe$ ssh arisawa@mmac > The authenticity of host 'mmac (192.168.1.7)' can't be established. > RSA key fingerprint is 80:0a:fc:62:42:e1:22:5b:81:ee:2d:21:b2:bc:ee:75. > Are you sure you want to continue connecting (yes/no)? yes > Warning: Permanently added 'mmac,192.168.1.7' (RSA) to the list of known > hosts. > Password: > Last login: Thu May 23 06:55:11 2013 > -bash$ > > I don't understand the difference of ssh server between linux and osx. > any suggestion is welcome. > anyone get connected to mac using ssh of Plan9? > > Kenji Arisawa >
Re: [9fans] ssh to osx
> the mac only enables "keyboard interactive" auth and not "password" auth, > these are very similar but different. you need to an option in a config file > on the mac to enable password auth. Based on the Unixes I'm familiar with, the sshd config file is in /etc/ssh and is unusual in that it does not have the more conventional .conf extension. It is specifically for SSHD, the server. Which needs to be restarted if the config is changed. ++L
[9fans] more plan9 software
C, public domain, no external deps. 1) https://bitbucket.org/ftrvxmtrx/xmpp Xmpp client. Supports multi-user chat and basic roster management. To compile on bell labs version, comment out xmpp.c:/Blethal, which is 9front specific, afaik. 2) https://bitbucket.org/ftrvxmtrx/cflood Flood-It/Color Flood clone. Not the first one, probably.
Re: [9fans] broken floating point exceptions and fpregs
On May 26, 2013, at 1:57, lu...@proxima.alt.za wrote: > It is unreasonable to expect a community to contribute to the > development of Plan 9 if the goal posts move with the fashion... You may agree or not with Erik's position, but this is an unreasonable characterization of it. It actually feels exactly backwards to me: he's proposing we *not* move the goalposts (or move them much less). I don't believe he's saying not to support SSE, but rather to support it in the more modern kernel. 386 would still be around, but putting effort into amd64 is likely the more productive use of time.
Re: [9fans] broken floating point exceptions and fpregs
> On May 26, 2013, at 1:57, lu...@proxima.alt.za wrote: > >> It is unreasonable to expect a community to contribute to the >> development of Plan 9 if the goal posts move with the fashion... > > You may agree or not with Erik's position, but this is an > unreasonable characterization of it. It actually feels exactly > backwards to me: he's proposing we *not* move the goalposts (or move > them much less). I don't believe he's saying not to support SSE, but > rather to support it in the more modern kernel. 386 would still be > around, but putting effort into amd64 is likely the more productive > use of time. I guess we're looking at the issue from different philosophical points of view and we miss the wood for the trees: Erik is in a position to use the most recent available equipment, my most recent "386" motherboard is the only one with SATA on board and an Intel 64-bit CPU. My criticism lies with a propensity to disregard the impact of following the fashion has on primitive equipment like mine: if SSE2 is _enforced_ as the only option (as nearly happened with Go - more about that in a minute), then, like Alef and IL, we'll lose conventional 387 capabilities and most of my equipment, specially some of my more expensive stuff like the co-located server in Cape Town, will become redundant. This has two drawbacks for me: (a) the comfortable niche Plan 9 found in my environment will be lost as I will no longer have the same confidence in Plan 9 I built in the last many years and (b) I will no longer have the equipment to assist with further development of Plan 9. Also, let me make it clear that I meant absolutely no disrespect towards Erik personally or of his contribution to the Plan 9 project; on the contrary, I have every reason to be grateful to Erik for the many ways in which he has assisted the project and, frequently, helped me personally. You seem to have misunderstood my position as criticising Erik for abandoning SSE2 on the 32-bit equipment. I was trying to suggest that we should not abandon 387 on the same and, to make things clear, I have no concern if we discard 387 capabilities in the 64-bit world, as long as we don't reflect that where 387 is the only option. I'm not sure how we got these wires crossed :-) Going back to the 387/SSE2 issue, in the Go development forum discussion has stopped without resolving the issue of how to deal with the need to continue to support the 387 instructions while also wanting to benefit from the more powerful and, I presume, efficient SSE2 alternative. As these are mutually exclusive (go figure!) the immediate problem is that the Go developers had to choose which option to release for Go 1.1. The choice went with SSE2, which means that a smaller number of users needed to build Go from sources. It was easy for me to agree with that decision, I'm prepared to pay a reasonable price to retain the ability to use Go and, in my case, I build Go from sources all the time anyway. I think those who cannot do so can probably pressure others besides the Go developers to release binary Go versions for slightly different architectures. There are two outstanding issues, though. On the one hand, the problem the Go developers faced is also a pain for Go users that want to release software (applications, for example) to the public. On the other, there is no clear strategy on how to hold different versions of the Go toolchain as well as Go applications for the 386 architecture: discrimination in the file system ends at the architecture and taking it a level further seems too burdensome for the nett gain. ++L
