Hi guys,
Anyone experiencing DECNET/HECNET connecting problems at the moment?
I noticed that http://www.update.uu.se/~bqt/hecnet.html is not currently responding.
It might be the setup at this end, but I've tried most things although I do appear to have a link through to psilo.update.uu.se:
192.168.1.127 4711 4711 130.238.19.25 4711 3 0
Non-authoritative answer:
psilo.update.uu.se canonical name = Psilocybe.update.uu.se.
Name: Psilocybe.update.uu.se
Address: 130.238.19.25
It could quite possibly be a problem at this end, given that SLAVE has not been up for a while...
Regards, Mark
Yeah, I think I had an older copy. Pulled the latest down and it built cleanly other than the MAX redefinition warning and the "openbsd thinks you're a moron for using strcpy()" warning.
All appears well as Sampsa can talk to HECnet via a bridge to me tunneled over OpenVPN. Ugly, but functional. :)
-brian
On 8/10/2012 6:54 AM, Johnny Billquist wrote:
Brian, could you verify that you have the latest version? I did some work to try and get rid of warnings a while back, and even though I'm sure some issues might be because of 64 bit issues, I would have expected some of the warnings you reported to have been fixed already...
Johnny
On 2012-08-09 21:00, Brian Hechinger wrote:
I'm trying to get the bridge built on OpenBSD 5.1 64-bit but it keep
segfaulting. Anyone ever get this working?
# cc -O2 -Wall -o bridge bridge.c -lpcap
bridge.c:65:1: warning: "MAX" redefined
In file included from /usr/include/netdb.h:90,
from bridge.c:32:
/usr/include/sys/param.h:191:1: warning: this is the location of the
previous definition
bridge.c: In function 'add_bridge':
bridge.c:241: warning: implicit declaration of function 'inet_aton'
bridge.c:263: warning: format '%d' expects type 'int', but argument 2
has type 'char *'
bridge.c:263: warning: format '%d' expects type 'int', but argument 3
has type 'char *'
bridge.c: In function 'add_service':
bridge.c:276: warning: format '%s' expects type 'char *', but argument 3
has type 'struct BRIDGE *'
bridge.c: In function 'dump_data':
bridge.c:524: warning: implicit declaration of function 'inet_ntoa'
bridge.c:531: warning: format '%s' expects type 'char *', but argument 4
has type 'int'
bridge.c: In function 'main':
bridge.c:564: warning: unused variable 'port'
bridge.c:561: warning: unused variable 'len'
/tmp//cc69aRp2.o(.text+0x934): In function `add_bridge':
: warning: strcpy() is almost always misused, please use strlcpy()
# cp bridge /var/bridge/
# cd /var/bridge/
# ./bridge 4711
Adding router ''local''. 00000000:0
Adding router ''sampsa''. 0afc2a0a:4711
Adding DECnet bridge local.
Trying to match local
Matching against: local
Found match: local == local
Adding DECnet bridge sampsa.
Trying to match sampsa
Matching against: local
Matching against: sampsa
Found match: sampsa == sampsa
Adding LAT bridge local.
Trying to match local
Matching against: local
Found match: local == local
Adding LAT bridge sampsa.
Trying to match sampsa
Matching against: local
Matching against: sampsa
Found match: sampsa == sampsa
Host table:
Segmentation fault (core dumped)
-brian
What I meant is that the os fit was done in firmware. Not, like the VAX, where the instruction set was designed to match demands from the os. IIRC the queue instructions aren't part of the Alpha instruction set.
On or off topic? It's Digital Lore, right :-)
-----Original Message-----
From: Phil Mendelsohn <phil at rephil.org>
Sender: owner-hecnet at Update.UU.SE
Date: Fri, 10 Aug 2012 16:29:00
To: <hecnet at Update.UU.SE>
Reply-To: hecnet at Update.UU.SESubject: Re: [HECnet] AXP Emulation
On 10/08/2012 3:10 PM, Paul_Koning at Dell.com wrote:
On Aug 10, 2012, at 4:07 PM, <hvlems at zonnet.nl>
wrote:
Correct, Windows started off on four platforms so the intimacy of VMS with the VAX was just not there. But VMS was a lot farther away from Alpha too.
I don't think that's accurate.
Most operating systems are not closely tied to a specific platform. And in the case of VMS, the Alpha architecture had some specific attributes that were meant to make porting VMS easier.
I agree. Alpha architecture was done with a posteriori and first-hand
internal knowledge of VMS and where it was headed / what it's customers
needed. I had a pre-release AXP Architecture Handbook which would
confirm, if I could lay my hands on the tree ware.
But this is OT, I suppose.
Phil M
--
"Worry is a misuse of imagination." -- Some Guy Called Dan Zadra
On 10/08/2012 3:10 PM, Paul_Koning at Dell.com wrote:
On Aug 10, 2012, at 4:07 PM, <hvlems at zonnet.nl>
wrote:
Correct, Windows started off on four platforms so the intimacy of VMS with the VAX was just not there. But VMS was a lot farther away from Alpha too.
I don't think that's accurate.
Most operating systems are not closely tied to a specific platform. And in the case of VMS, the Alpha architecture had some specific attributes that were meant to make porting VMS easier.
I agree. Alpha architecture was done with a posteriori and first-hand internal knowledge of VMS and where it was headed / what it's customers needed. I had a pre-release AXP Architecture Handbook which would confirm, if I could lay my hands on the tree ware.
But this is OT, I suppose.
Phil M
--
"Worry is a misuse of imagination." -- Some Guy Called Dan Zadra
On 08/10/2012 05:21 PM, Paul_Koning at Dell.com wrote:
Try adding -fomit-frame-pointer; that will free up a register, which
is pretty important on register-starved architectures such as x86 and
x86_64. (depending on your -O<n> level, it might already be turned on
though)
According to the manpage, that's already the default as of GCC V4.6. I'm currently doing some tests with GCC 4.7.0, the latest release.
Cool. But...the default? With no frame pointers, debugging is pretty
difficult. I assume it's only enabled with -O[n], and disabled with
-g[xxx]?
No, but you can enable frame pointers if you need them. Depending on the debugger, you may not need them. For example, MIPS seems to have them in theory, but in practice there is no reason to use them (except if a function calls alloca() in which case GCC forces a frame pointer for that one function).
Interesting! I didn't know that. Thanks for the info!
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On Aug 10, 2012, at 5:06 PM, Dave McGuire wrote:
On 08/10/2012 04:29 PM, Paul_Koning at Dell.com wrote:
Try adding -fomit-frame-pointer; that will free up a register, which
is pretty important on register-starved architectures such as x86 and
x86_64. (depending on your -O<n> level, it might already be turned on
though)
According to the manpage, that's already the default as of GCC V4.6. I'm currently doing some tests with GCC 4.7.0, the latest release.
Cool. But...the default? With no frame pointers, debugging is pretty
difficult. I assume it's only enabled with -O[n], and disabled with
-g[xxx]?
No, but you can enable frame pointers if you need them. Depending on the debugger, you may not need them. For example, MIPS seems to have them in theory, but in practice there is no reason to use them (except if a function calls alloca() in which case GCC forces a frame pointer for that one function).
paul
On 08/10/2012 04:29 PM, Paul_Koning at Dell.com wrote:
Try adding -fomit-frame-pointer; that will free up a register, which
is pretty important on register-starved architectures such as x86 and
x86_64. (depending on your -O<n> level, it might already be turned on
though)
According to the manpage, that's already the default as of GCC V4.6. I'm currently doing some tests with GCC 4.7.0, the latest release.
Cool. But...the default? With no frame pointers, debugging is pretty
difficult. I assume it's only enabled with -O[n], and disabled with
-g[xxx]?
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
oddly enough the Alpha compiler on NT was HORRIBLE... And it had DEC strewn all over its copyrites so I suspect it wasn't a 100% Microsoft thing.. Naturally by the time you could compile with O2 and have the exe actually run properly support for the Alpha was dropped in the Compaq HP acquisition.
Even the leaked NT source complained bitterly about the Alpha C compiler..
Oh well it's all ancient history now.
On Fri, Aug 10, 2012 at 4:07 PM, <hvlems at zonnet.nl> wrote:
Correct, Windows started off on four platforms so the intimacy of VMS with the VAX was just not there. But VMS was a lot farther away from Alpha too.
The reason support for Windows was dropped for all platforms other than IA32 and IA64 indicates that it is too costly if not impossible to engineer.
After all these years Windows settled nicely on IA32.
What Microsoft probably lacks is DEC's compiler architects. Those guys live with Intel now and performance these days is very much their line of business.
It wouldn't surprise me if Intel and Microsoft did do a little bit of joint engineering since 1998.
-----Original Message-----
From: Phil Mendelsohn <phil at rephil.org>
Sender: owner-hecnet at Update.UU.SE
Date: Fri, 10 Aug 2012 13:29:06
To: <hecnet at Update.UU.SE>
Reply-To: hecnet at Update.UU.SESubject: Re: [HECnet] AXP Emulation
On 10/08/2012 10:51 AM, hvlems at zonnet.nl wrote:
> Windows is a relative of vms, an ugly cousin but still family. Its growth is stunted, Windows 7 is the fifth version after W 3.5. VMS grew a lot faster, with more (end user) functionalty, more stability during its first two decades.
> Even then Windows 5.1 (aka XP) is stable and useful. Vista wasn't then again VMS 6.1 wasn't that mature either...
But VMS had the advantage that it and the processor (VAX) that ran it
were designed in concert. x86 architecture and Windows are more a case
of being cobbled together iteratively and separately.
--
"Worry is a misuse of imagination." -- Some Guy Called Dan Zadra
