Re: [9fans] telnet

Re: [9fans] telnet

[Dan Cross]

> > Where's Dan anyhow? Have not seen a post from him for a while.
> 
> don't know.  i sent a postcard, sealed in a reasonably tamper
> proof envelope, to parris island but it got returned.  he didn't
> give me his unit # etc so i guess they just bounced it, complete
> with an impressive set of stamps.
> 
> i've poked around in /adm/users on brahma to see if there
> was anyone in there who looked like they might know, but
> didn't find anything like.  the other choice was to spam
> /adm/users which didn't seem like a plan.  he's somewhere
> in the Corps.
> 
> i asked some other .mil people i know and they couldn't
> really help either.  i hope he's ok.

Yeah, I'm fine.  I was gone for three months, but I'm back on leave for
a few days, and then shipping off again.  For those of you who don't
know, I'm also a United States Marine and am on active duty right now.
I'll try and do better about staying in touch, which should be feasible
starting in late May or early June.

	- Dan C.

[9fans] telnet

[boyd, rounin]

it seems that telnet has departed from the man page and the
utility of using it (albiet not strictly correctly) with smtp, pop,
ftp etc ... has also been lost.

here is a diff so you can:

    telnet host

    telnet host!service

service can be textual or numeric.

as far as i can see 'net' [see netmkaddr] will always be 'tcp'.

brahma% diff /n/sources/plan9/sys/src/cmd/ip telnet.c
41c41
<  fatal("usage: telnet [-Cdnr] net!host[!service]", 0, 0);
---
>  fatal("usage: telnet [-Cdnr] host[!service]", 0, 0);
80a81,85
> enum {
>  Thost,
>  Tservice,
> };
> 
82c87
<  *  dial and return a data connection
---
>  *  dial host[!service] and return a data connection
89a95,96
>  int n;
>  char *to[2];
91c98,110
<  name = netmkaddr(dest, "tcp", "telnet");
---
>  to[Thost] = dest;
>  to[Tservice] = "telnet";
> 
>  switch (n = getfields(dest, to, nelem(to), 0, "!")) {
>  case 2:
>  case 1:
>   break;
> 
>  default:
>   usage();
>  }
> 
>  name = netmkaddr(to[Thost], "tcp", to[Tservice]);

all done with drawterm [to NY], mousepad and 2 buttons.

i have not hacked the man page into shape.

Re: [9fans] telnet

[boyd, rounin]

damn, 'int n;' is redundant, but was written with some hope to do:

    net!host!service

two selects and cuts and it's gone.

Re: [9fans] telnet

[Russ Cox]

telnet tcp!host!pop3 works fine with the current source code.
telnet host!pop3 has never worked -- a!b means net!host.

Re: [9fans] telnet

[boyd, rounin]

> telnet tcp!host!pop3 works fine with the current source code.
> telnet host!pop3 has never worked -- a!b means net!host.

i know that.

telnet's net is tcp, so net is rather redundant.

Re: [9fans] telnet

[Russ Cox]

> telnet's net is tcp, so net is rather redundant.

so let's make it different from every other program?

there might be more than one tcp.  right now it 
works great to run telnet /net.alt/tcp!outside-machine.

why does it need to be tcp?  it just shuttles
bytes around if it's not connecting to a telnet port,
so telnet il!emelie!9fs works fine.

Re: [9fans] telnet

[boyd, rounin]

> there might be more than one tcp.  right now it 
> works great to run telnet /net.alt/tcp!outside-machine.

all the world is not 11271.  /net or /net.alt should be irrelevant.
the routing should just work.  it does on lunix and the last time
i was in the unix room binding /net.alt it just worked too.

> why does it need to be tcp?

it doesn't.

> it just shuttles bytes around if it's not connecting to a telnet port,
> so telnet il!emelie!9fs works fine.

il died years ago.

it should be transparent, and as i've said before the CODE bound
it to 'net' 'tcp'.  it should also allow the flexibility to choose how
you want to connect.

but these are all moot points.  telnet talks tcp, for almost all cases.
the code in netmkaddr() and telnet play games, which should not
be played.

Re: [9fans] telnet

[Russ Cox]

you're wrong.

addresses passed to telnet should be
interpreted the same way as they are 
by all the other programs.  there is no
good reason telnet should be different,
except that for some reason you refuse
to type four extra characters.  if you want
to do less typing, use 

    con tcp!host!pop3

instead of

    telnet tcp!host!pop3

Re: [9fans] telnet

[boyd, rounin]

> you're wrong.

i don't think so.

>     telnet tcp!host!pop3

telnet implies the telnet protocol.

let's leave it as a Taylor Class 1 'argument'.

Re: [9fans] telnet

[Charles Forsyth]

>> if you want
>>to do less typing, use 

a script
a function

Re: [9fans] telnet

[Richard Miller]

> il died years ago.

Not quite dead yet, just very il.

All my local machines are linked with il - is there really nobody else
outside 11271 who still does this?

Re: [9fans] telnet

[boyd, rounin]

> All my local machines are linked with il - is there really nobody else
> outside 11271 who still does this?

good question.

Re: [9fans] telnet

[Fco.J.Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 7 bytes --]

I do.

[-- Attachment #2: Type: message/rfc822, Size: 2057 bytes --]

From: "boyd, rounin" <boyd@insultant.net>
To: <9fans@cse.psu.edu>
Subject: Re: [9fans] telnet
Date: Fri, 23 Apr 2004 10:12:10 +0200
Message-ID: <017901c4290a$ad8a24a0$48db7d50@SOMA>

> All my local machines are linked with il - is there really nobody else
> outside 11271 who still does this?

good question.

Re: [9fans] telnet

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 577 bytes --]

i use il on nearly all my/our systems for file service.
indeed, given that two of them use /sys/src/fs as kernel
and one of those has a jukebox, that's nearly essential,
but even otherwise, i'm not convinced that il can't
be made to outperform tcp/ip on some network/transport types
(eg, because of Ildataquery), and compared to some code modules
that need to be kept compiling, it's anyway not all that big.

apart from il, i have used telnet (with the telnet protocol) over ILAP
and also in environments where /net.alt was indeed a distinct stack,
amongst others.

[-- Attachment #2: Type: message/rfc822, Size: 1778 bytes --]

From: Richard Miller <rm@hamnavoe.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] telnet
Date: Fri, 23 Apr 2004 09:06:03 +0100
Message-ID: <8f86534e5595a20e23cdb43c26f66de6@hamnavoe.com>

> il died years ago.

Not quite dead yet, just very il.

All my local machines are linked with il - is there really nobody else
outside 11271 who still does this?

Re: [9fans] telnet

[boyd, rounin]

why not bind your chosen /net* (on a per window basis) and then telnet?

Re: [9fans] telnet

[Geoff Collyer]

[-- Attachment #1: Type: text/plain, Size: 106 bytes --]

Sometimes that works, but sometimes one needs access to inside and
outside networks in the same window.

[-- Attachment #2: Type: message/rfc822, Size: 2094 bytes --]

From: "boyd, rounin" <boyd@insultant.net>
To: <9fans@cse.psu.edu>
Subject: Re: [9fans] telnet
Date: Fri, 23 Apr 2004 10:35:08 +0200
Message-ID: <019d01c4290d$e2d833b0$48db7d50@SOMA>

why not bind your chosen /net* (on a per window basis) and then telnet?

Re: [9fans] telnet

[a]

my own network uses il for its internal communication; it's
four boxes including one ken-fs.

i have saved somewhere performance numbers presotto came
up with about a year or two ago. in those, il consistently
outperformed tcp, but the margin got smaller and smaller
as link speed went up, so it was considered not worth it.
ア

Re: [9fans] telnet

[Charles Forsyth]

>>as link speed went up, so it was considered not worth it.

network characteristics are not all tending towards unformly
high link speeds with uniformly low error rate,
and the need to conserve power can be important as well.  i think it's also interesting
having a connection protocol oriented towards rpc (-ish) interactions
not varying undelimited byte streams.   there probably are other candidates
but the code is already there for this one.

on small devices i sometimes ditch tcp completely in favour of il and/or
other things.

Re: [9fans] telnet

[a]

i also like IL in theory (and much prefer it to tcp, certainly).
but it's increasingly difficult to use. maintaining the code is
the smallest part of this issue. most nat boxes will choke
outright or drop the packets on the floor (actually, will any 
pass IL?), and many ISPs won't deal well with IL, either. you
just don't get real, unfiltered IP any more (at least reliably).

it's also frustrating that IL never got outside Plan 9 and
Inferno (and one now-defunct BSD project). it makes the
cost/benefit ratio for working to get IL passed much less
enticing if i can't, say, drawterm using it.

of course, you could s/IL/9P/g in that last paragraph without
affecting the truth value of the statement.
ア

Re: [9fans] telnet

[Brantley Coile]

> on small devices i sometimes ditch tcp completely in favour of il and/or
> other things.

Back in 1996 we tried to use il over the Cisco internal network.  Somewhere
in the network some one was filtering out non-standard protocol packets.
(I know that's broken.)  What has been your experience in using il across
public networks?  I would like to use it in an application, maybe.

Re: [9fans] telnet

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 242 bytes --]

i've had no trouble with that on the networks i use.
my cable supplier gives me a full proper ipv4 connection.
rj45 and off i go.

i can see how some firewalls and some nat might get in the way
depending on capability or configuration.

[-- Attachment #2: Type: message/rfc822, Size: 1979 bytes --]

From: Brantley Coile <bwc@coraid.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] telnet
Date: Fri, 23 Apr 2004 08:38:34 -0400
Message-ID: <2906846ac9f64a3c0b87ac712e63d125@borf.com>

> on small devices i sometimes ditch tcp completely in favour of il and/or
> other things.

Back in 1996 we tried to use il over the Cisco internal network.  Somewhere
in the network some one was filtering out non-standard protocol packets.
(I know that's broken.)  What has been your experience in using il across
public networks?  I would like to use it in an application, maybe.

Re: [9fans] telnet

[boyd, rounin]

> What has been your experience in using il across
> public networks?

that's the real question.

Re: [9fans] telnet

[Axel Belinfante]

> > il died years ago.
> 
> Not quite dead yet, just very il.
> 
> All my local machines are linked with il - is there really nobody else
> outside 11271 who still does this?

My file server still runs ken (non-fossil) fs and thus only speaks il.
(transition to venti/fossil still in progress -
 I have fossil (non-venti), and a venti running,
 but not for the main file system)

The home machine used to connect over tcp via trampoline on cpu server,
nowadays it imports/aan the root fs from the cpu server.

Axel.

Re: [9fans] telnet

[Geoff Collyer]

I'm still using IL to the original file server.  At least until I've
beaten on fossil for a long time and had it not fail, I'm sticking to
Ken's.  A failed fossil may be easy to reinitialiase, with its data in
venti, but that's not really good enough for unattended operation.  I
may also want to continue using optical jukeboxes, so there's some
code to move to user-land from Ken's fs.

Re: [9fans] telnet

[Fco.J.Ballesteros]

> I'm still using IL to the original file server.  At least until I've
> beaten on fossil for a long time and had it not fail, I'm sticking to
> Ken's.  A failed fossil may be easy to reinitialiase, with its data in
> venti, but that's not really good enough for unattended operation.  I
> may also want to continue using optical jukeboxes, so there's some
> code to move to user-land from Ken's fs.

Our file system runs mostly unattended. I admit a cron reboots it
once a week, but that's for safety :-)

Re: [9fans] telnet

[Geoff Collyer]

What do you think would happen if you didn't reboot once a week?

Re: [9fans] telnet

[Fco.J.Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 373 bytes --]

I think I'd have memory leaks and the file server (which
is also the web, mail, blah... server) would degrade.

Once a week is a good guarantee for me that I can forget
about any kind of leaks.

I think the lack of user processes in Ken's is a feature, not a bug.
Sometimes I've even thought about forbidding all kind of
processes (but fossil) in the file server.

[-- Attachment #2: Type: message/rfc822, Size: 1673 bytes --]

From: Geoff Collyer <geoff@collyer.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] telnet
Date: Fri, 23 Apr 2004 01:44:36 -0700
Message-ID: <00de823c52c54e81247cc4cccb1d1227@collyer.net>

What do you think would happen if you didn't reboot once a week?

Re: [9fans] telnet

[boyd, rounin]

if everything is a file why can't i telnet to
/net*/tcp/pop.insultant.net/pop3?

/net* could be completely synthetic.

Re: [9fans] telnet

[Richard Miller]

> if everything is a file why can't i telnet to
> /net*/tcp/pop.insultant.net/pop3?

There already seems to be some movement towards this naming convention,
eg in upasfs(4):

          Fs interprets mailbox file names of the form
          /proto/host/user to mean access an account on host using the
          given protocol.

Re: [9fans] telnet

[Geoff Collyer]

/sys/doc/net/net.ms:661,687, reformatted:

Several possible solutions were considered and rejected; one deserves
more discussion.  We could have used a user-level file server to
represent the network name space as a Plan 9 file tree.  This global
naming scheme has been implemented in other distributed systems.  The
file hierarchy provides paths to directories representing network
domains.  Each directory contains files representing the names of the
machines in that domain; an example might be the path
/net/name/usa/edu/mit/ai.  Each machine file contains information like
the IP address of the machine.  We rejected this representation for
several reasons.  First, it is hard to devise a hierarchy encompassing
all representations of the various network addressing schemes in a
uniform manner.  Datakit and Ethernet address strings have nothing in
common.  Second, the address of a machine is often only a small part
of the information required to connect to a service on the machine.
For example, the IP protocols require symbolic service names to be
mapped into numeric port numbers, some of which are privileged and
hence special.  Information of this sort is hard to represent in terms
of file operations.  Finally, the size and number of the networks
being represented burdens users with an unacceptably large amount of
information about the organization of the network and its
connectivity.  In this case the Plan 9 representation of a resource as
a file is not appropriate.

Re: [9fans] telnet

[boyd, rounin]

> Each directory contains files representing the names of the
> machines in that domain; an example might be the path
> /net/name/usa/edu/mit/ai.  Each machine file contains information like
> the IP address of the machine.  We rejected this representation for
> several reasons.  ...

i have to disagree.  the ! addressing no different from / [file]
addressing.  you can synthesise the file tree based on context.

a!b!c as a comand line argumeet is just that, whereas user
mode fileservers can do whatever they like.  getting the
structure of the file tree may be tricky, but that's what
makes it interesting.

a!b!c goes all the way back to datakit and uucp.  i'd
say it's time to dump it.  if you want shortcuts use bind(1).

EGREG?

;)

Re: [9fans] telnet

[Russ Cox]

> i have to disagree.  the ! addressing no different from / [file]
> addressing.  you can synthesise the file tree based on context.

cd /net/name/usa/edu; ls

Re: [9fans] telnet

[Dave Lukes]

On Sun, 2004-04-25 at 04:35, Russ Cox wrote:
> > i have to disagree.  the ! addressing no different from / [file]
> > addressing.  you can synthesise the file tree based on context.

I have to disagree with the disagreement:
in this context
	Context = RandomRFCMush * random_practice_on_the_internet

Now, if someone wants to write a file server that understands
the minds of the creators, high priests and supplicants of that
ginormous tin god DeeEnEss, then good luck to them.

I look forward eagerly to the skeleton design spec,
due early next millennium.

> cd /net/name/usa/edu; ls

Amen.
	Dave.

Re: [9fans] telnet

[boyd, rounin]

> I look forward eagerly to the skeleton design spec,
> due early next millennium.
> 
> > cd /net/name/usa/edu; ls

we [Digital research sysadmins: CRL/NSL/PRL/SRC] had a design in '92.

Re: [9fans] telnet

[rog]

> i have to disagree.  the ! addressing no different from / [file]
> addressing.  you can synthesise the file tree based on context.

how's the server meant to guess the authentication/firewall
hoops you have to jump through to get access to the remote
server? just naming it is not sufficient.

Re: [9fans] telnet

[rog]

> There already seems to be some movement towards this naming convention,
> eg in upasfs(4):
> 
>           Fs interprets mailbox file names of the form
>           /proto/host/user to mean access an account on host using the
>           given protocol.

i'm not too keen on this kind of thing, in addition to the reasons
quoted by geoff, because such a directory structure is inherently
unenumerable.

moreover it's not very clear how long the connection to the remote
machine should stay valid.  do you guess, and have a timeout cache?
do you make the connection close down when the last reference goes
away (which you might not want either)?

what if i want "host" to be "/net.alt/tcp!somehost.com"?

this was the kind of thing that might be solved reasonably
elegantly, i think, by that "idea" i mentioned in a previous post.
(which i kind of expected a little discussion on, but there y'go)

Re: [9fans] telnet

[Russ Cox]

> > There already seems to be some movement towards this naming convention,
> > eg in upasfs(4):
> >
> >           Fs interprets mailbox file names of the form
> >           /proto/host/user to mean access an account on host using the
> >           given protocol.
> 
> i'm not too keen on this kind of thing, in addition to the reasons
> quoted by geoff, because such a directory structure is inherently
> unenumerable.

the upas/fs hack was never intended to stand as an
example of the way things ought to be done.  it solved
the problem of naming remote mailboxes and it has served
well, but as geoff pointed out, it is very much not a good
idea in general.  it's not even a good idea in this case (as
rog points out) but it does happen to get the job done
some useful fraction of the time.

Re: [9fans] telnet

[Geoff Collyer]

I am intrigued by your (rog's) idea.  I've just been very busy of
late.

Re: [9fans] telnet

[andrey mirtchovski]

> What do you think would happen if you didn't reboot once a week?

i leave my fossil/venti fs untouched unless there's a need to update
the kernel -- i simply dislike rebooting as an event, unless it's a
terminal, in which case i only care if it happens without warning.

i regurarly run uptimes of a month, and now that fossil has been
stable for a while i expect those to increase.

generally there are no trivially observable leaks in fossil.  the
memory footprint has stayed the same, in the hundreds of kilobytes, in
the past 24 days since the last reboot.  overall memory usage does
increase, but that's mostly from programs that refuse to die after you
delete their windows.

of course i'm nowhere near the unattendancy of a ken fs.  just checked
dan cross' cpu server -- it's been up for:

	brahma up 186 days, 22:17:03

andrey

Re: [9fans] telnet

[9nut]

> of course i'm nowhere near the unattendancy of a ken fs.  just checked
> dan cross' cpu server -- it's been up for:
> 
> 	brahma up 186 days, 22:17:03

Where's Dan anyhow? Have not seen a post from him for a while.

Re: [9fans] telnet

[boyd, rounin]

> Where's Dan anyhow? Have not seen a post from him for a while.

don't know.  i sent a postcard, sealed in a reasonably tamper
proof envelope, to parris island but it got returned.  he didn't
give me his unit # etc so i guess they just bounced it, complete
with an impressive set of stamps.

i've poked around in /adm/users on brahma to see if there
was anyone in there who looked like they might know, but
didn't find anything like.  the other choice was to spam
/adm/users which didn't seem like a plan.  he's somewhere
in the Corps.

i asked some other .mil people i know and they couldn't
really help either.  i hope he's ok.

Re: [9fans] telnet

[boyd, rounin]

> of course i'm nowhere near the unattendancy of a ken fs.  just checked
> dan cross' cpu server -- it's been up for:
> 
> brahma up 186 days, 22:17:03

brahma is unattended 'cos dan is in the Corps, somewhere.

Re: [9fans] telnet

[boyd, rounin]

> Our file system runs mostly unattended. I admit a cron reboots it
> once a week, but that's for safety :-)

i wouldn't define that as 'unattended'.

machines used to run for months to years without reboots.

Re: [9fans] telnet

[Fco.J.Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 367 bytes --]

I don't run uptime races, I prefer to trust the machine.
In fact, Ken's (on IDE) also degraded in our case (although
much more slowly).

I think that "all servers have leaks" is a tautology, and therefore,
I use reboot as the tool to fix that problem (Not that I don't try to fix
leaks, just that I don't trust that all of them can be both detected and
fixed).

[-- Attachment #2: Type: message/rfc822, Size: 2149 bytes --]

From: "boyd, rounin" <boyd@insultant.net>
To: <9fans@cse.psu.edu>
Subject: Re: [9fans] telnet
Date: Fri, 23 Apr 2004 10:51:02 +0200
Message-ID: <01bb01c42910$1ba8a830$48db7d50@SOMA>

> Our file system runs mostly unattended. I admit a cron reboots it
> once a week, but that's for safety :-)

i wouldn't define that as 'unattended'.

machines used to run for months to years without reboots.

Re: [9fans] telnet

[boyd, rounin]

> I use reboot as the tool to fix that problem (Not that I don't try to fix
> leaks, just that I don't trust that all of them can be both detected and
> fixed).

that is not a fix.  it's a hack.

Re: [9fans] telnet

[Geoff Collyer]

I've never seen leaks nor degradation with Ken's fs and I only reboot
it to change hardware, boot a new fs kernel, or move the machine.
Ken's fs is just slower on IDE because the IDE code doesn't use DMA.

Re: [9fans] telnet

[Fco.J.Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 472 bytes --]

I've seen problems, but as I say, I used it only on
IDE disks. Although IMHO, some problems were due to
locking and had to do with the network card. I'm sorry,
but I don't remember the details.

It may stay up for a year, I don't know; I'm just saying that
the longer is the uptime, the more scared I get (because,
IMHO, the sooner it's going to fail). Of course, I'm not
saying that Ken's is not reliable. In fact, I consider fossil
and venti reliable as well.

[-- Attachment #2: Type: message/rfc822, Size: 1815 bytes --]

From: Geoff Collyer <geoff@collyer.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] telnet
Date: Fri, 23 Apr 2004 02:08:41 -0700
Message-ID: <e73a4924f83dfcc7de03a0cd1125c960@collyer.net>

I've never seen leaks nor degradation with Ken's fs and I only reboot
it to change hardware, boot a new fs kernel, or move the machine.
Ken's fs is just slower on IDE because the IDE code doesn't use DMA.

Re: [9fans] telnet

[C H Forsyth]

>>It may stay up for a year, I don't know; I'm just saying that
>>the longer is the uptime, the more scared I get (because,
>>IMHO, the sooner it's going to fail). Of course, I'm not

i'm curious: if you have been well for a fairly long time
do you take to your bed because you must surely be about to come
down with something?

Re: [9fans] telnet

[Fco.J.Ballesteros]

> i'm curious: if you have been well for a fairly long time
> do you take to your bed because you must surely be about to come
> down with something?

Nope. My body does that for me. My cells get dead and
replaced by other ones, you know.

I just can't do that with the computer, so I do it with
the whole thing.

Re: [9fans] telnet

[Brantley Coile]

> I've never seen leaks nor degradation with Ken's fs and I only reboot
> it to change hardware, boot a new fs kernel, or move the machine.
> Ken's fs is just slower on IDE because the IDE code doesn't use DMA.

A few month ago we replaces ramac our 20GB ken fs.  It had run, rebooting
only as a result of a power failure.  It would run for many months at a time.
We replaced it with the new IDE version.  Works for us.

Re: [9fans] telnet

[ron minnich]

On Fri, 23 Apr 2004, Fco.J.Ballesteros wrote:

> Our file system runs mostly unattended. I admit a cron reboots it
> once a week, but that's for safety :-)

that's ok but not near good enough. I know lotsa people dislike linux but
fact is 2-3 year uptimes are normal and boring nowadays, also true for BSD
(in fact BSD usually still does a bit better, 2-3 year uptime was boring 8
years ago).

Fossil is quite neat but needs the hardening steps. I'm well aware that
nobody has the time but we ought to be aware of what is possible. 

ron

Re: [9fans] telnet

[Fco.J.Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 211 bytes --]

We gather stats nightly and try to find out leaks and the like.
Of course, we all like our file system to be solid as a rock
(Ken was mostly there--modulo the bugs we suffered).

I, mostly, agree with you.

[-- Attachment #2: Type: message/rfc822, Size: 2818 bytes --]

From: ron minnich <rminnich@lanl.gov>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] telnet
Date: Fri, 23 Apr 2004 08:38:13 -0600 (MDT)
Message-ID: <Pine.LNX.4.44.0404230835130.19442-100000@maxroach.lanl.gov>

On Fri, 23 Apr 2004, Fco.J.Ballesteros wrote:

> Our file system runs mostly unattended. I admit a cron reboots it
> once a week, but that's for safety :-)

that's ok but not near good enough. I know lotsa people dislike linux but
fact is 2-3 year uptimes are normal and boring nowadays, also true for BSD
(in fact BSD usually still does a bit better, 2-3 year uptime was boring 8
years ago).

Fossil is quite neat but needs the hardening steps. I'm well aware that
nobody has the time but we ought to be aware of what is possible. 

ron

Re: [9fans] telnet

[andrey mirtchovski]

> Fossil is quite neat but needs the hardening steps. I'm well aware that
> nobody has the time but we ought to be aware of what is possible. 

fossil needs to be rewritten in limbo :)

*ducks*

Re: [9fans] telnet

[Dave Lukes]

> All my local machines are linked with il - is there really nobody else
> outside 11271 who still does this?

Not yet ... but I'm
a) irrascible enough,
b) will be running a wlan at some point

that I might possibly do that to
a) rebel against established standards
b) get some security through obscurity
c) keep P9 on it's toes WRT multiple protocols.
d) see how well it works.

:-)
	Dave.

Re: [9fans] telnet

[Charles Forsyth]

>>c) keep P9 on it's toes WRT multiple protocols.

yes, i also thought there was something to be said for that.

Re: [9fans] telnet

[Brantley Coile]

>> il died years ago.
> 
> Not quite dead yet, just very il.
> 
> All my local machines are linked with il - is there really nobody else
> outside 11271 who still does this?

We still use it.  We're still running ken fs down here.

 Brantley

Re: [9fans] telnet

[9nut]

>>> il died years ago.
>> 
>> Not quite dead yet, just very il.
>> 
>> All my local machines are linked with il - is there really nobody else
>> outside 11271 who still does this?
> 
> We still use it.  We're still running ken fs down here.

Same here. As far as reliability, ken fs outperforms Puget Power,
our local power company.

"The news of my death has been greatly exaggerated" -- Mark Twain

Re: [9fans] telnet

[Charles Forsyth]

>>all the world is not 11271.  /net or /net.alt should be irrelevant.
>>the routing should just work.  it does on lunix and the last time

/net.alt is often used to AVOID having routing between the networks,
which is exactly why someone added a bizarre scheme to xBSD to get a
similar effect to Plan 9's having distinct network stacks on #I0 #I1 ...

reaches for B-52

Re: [9fans] telnet

[boyd, rounin]

> reaches for B-52

ARC LIGHT?

Re: [9fans] telnet

[boyd, rounin]

> telnet tcp!host!pop3 works fine with the current source code.
> telnet host!pop3 has never worked -- a!b means net!host.

then again, 'tcp' is not a net it's a protocol.

and "tcp" is hard coded with a aforementioned constant in telnet.c