Al 27/02/13 09:42, En/na Dave McGuire ha escrit:
I assume all of this is in the repository...Is there going to be a new
release soon?
Mark tagged the current HEAD as beta some weeks ago, but there is no word about the release date yet. For what I'm seeing, there are no serious bugs in the current master branch, at least in the VAX and PDP-11 simulators. I have been using the testing versions for a time, and they seem to be stable.
Of course beware there could be obscure bugs... for instance we catched one in the PDP-11 simulator which manifested itself JUST at the SAV /WB command... The simulator worked fine thru the SYSGEN time... just to render your disk unbootable after SAVing the new system image. :)
I assume all of this is in the repository...Is there going to be a new
release soon?
-Dave
On 02/27/2013 02:53 AM, Jordi Guillaumes i Pons wrote:
Yes! And microVAX I and II as well as 11/730, 11//750 and a VAXrt.
As for the accuracy, I know it does the full VAX instruction set (including compatibility mode) but can't be sure about the bus and hardware. I know it does not have an emulated PDP11 as console, so it is certainly not 100% accurate.
Jordi Guillaumes i Pons
Barcelona - Catalunya - Europa
El 27/02/2013, a les 1:09, Johnny Billquist <bqt at softjar.se> va escriure:
Say what? Have simh added VAX 8600 emulation? Do you know how accurate that is? I have plenty of code for NetBSD which plays with that machine (I have a real machine to work on).
--
Dave McGuire, AK4HZ
New Kensington, PA
Yes! And microVAX I and II as well as 11/730, 11//750 and a VAXrt.
As for the accuracy, I know it does the full VAX instruction set (including compatibility mode) but can't be sure about the bus and hardware. I know it does not have an emulated PDP11 as console, so it is certainly not 100% accurate.
Jordi Guillaumes i Pons
Barcelona - Catalunya - Europa
El 27/02/2013, a les 1:09, Johnny Billquist <bqt at softjar.se> va escriure:
Say what? Have simh added VAX 8600 emulation? Do you know how accurate that is? I have plenty of code for NetBSD which plays with that machine (I have a real machine to work on).
On 2013-02-25 15:07, Jordi Guillaumes i Pons wrote:
Please add this node to the nodelist:
7.74 BITXOW (SIMH VAX 8600, OpenVMS 6.1)
Thanks!
Say what? Have simh added VAX 8600 emulation? Do you know how accurate that is? I have plenty of code for NetBSD which plays with that machine (I have a real machine to work on).
Anyway, node added.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On 2013-02-23 07:19, Julian Wolfe wrote:
We actually got a VPN going, and this solved the problem. My machine is part of Area 18 now and is called FLIND (18.777).
Excellent. I'll drop you on my bridge then.
You can remove BIGBOA (1.42) for the time being.
Done. (As well as FLIND)
Johnny
On Feb 22, 2013, at 2:55 PM, Johnny Billquist <bqt at softjar.se> wrote:
On 2013-02-22 19:37, Julian Wolfe wrote:
HI all,
Registered on HECnet many years ago, but was never able to get on for long or at all in the past. Now it seems this problem plagues me yet again in a different form.
I've got a PDP-11/23+ running RSTS/E 10.1 and DECnet/E 4.1 behind a DD-WRT router in my basement (WRT54GS, DD-WRT build 13064), and this is behind an AT&T U-Verse router. Something is going on with the packet source ports - they are being marked with a randomized source port.
My questions are: Does the source port matter, when using Johnny's bridge, and he knows my port?
If the port does matter, has anyone experienced this issue (specifically on AT&T U-Verse or otherwise) and solved it?
Is this something I can fix myself, or do I need to look for another solution?
The wierd part is, I used the bridge successfully for 2 days with the bridge installed on a Mac running Mac OS X 10.8. This machine was also talking through a different WRT54GS with DD-WRT build 13064 and identical settings to the other router (client bridged mode). I then moved the PDP to the basement with the rest of my servers, had it go through the linux box for the bridge, and suddenly the packets have this mangles source port. I tried switching it back to the Mac, and now this problem has cropped up there too.
Phew! Help! I just want to hang out with yous guys :)
I've hit the problem with mangled ports in the past. Yes, it certainly do matter for the bridge (or anything else using UDP). Not only a security issue, but you peer needs to know where to send his packets as well.
I have a hack to the bridge, which sortof adapts to this. Ping me sunday, when I have some more time...
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On 2013-02-26 21:24, Clem Cole wrote:
That sounds right. I've forgotten many of these details.
IIRC: DEC had something called "regions" that were bastardized by the
screen handlers like termcap et al to do some of the same things.
Horton (termcap and terminfo author) or Kent (terminal firmware author)
might remember.
Yeah. You can use the scroll region to do insert/delete lines. However, there is no help for insert/delete character. You just have to send it all on a VT100.
Johnny
Clem
On Mon, Feb 25, 2013 at 5:30 PM, Johnny Billquist <bqt at softjar.se
<mailto:bqt at softjar.se>> wrote:
As far as I know, the VT100 do not do insert and delete at all.
Those were added in the VT102...
That sounds right. I've forgotten many of these details.
IIRC: DEC had something called "regions" that were bastardized by the screen handlers like termcap et al to do some of the same things. Horton (termcap and terminfo author) or Kent (terminal firmware author) might remember.
Clem
On Mon, Feb 25, 2013 at 5:30 PM, Johnny Billquist <bqt at softjar.se> wrote:
As far as I know, the VT100 do not do insert and delete at all. Those were added in the VT102...
Johnny,
As part of the hub I'm setting up at my data centre, I'd like to also bridge directly to you. Could you please add a bridge to myst.platinum.net 199.166.5.172:4711. It is a static IP address. I have configured the bridge software on my end. let me know if I need to change the default destination of tempo.update.uu.se:4711.
Thanks!
Ian
Ok, one MAJOR rewrite later and this code is a little bit more sane.
One of the best parts is instead of the db returning little blurbs of "this is what changed" it now returns the inserted/updated/deleted rows as JSON that the python script can ingest and make much better decisions with.
I've got some ideas for stuff I want to add now but I'm pretty happy with where it is now.
I'm also open to ideas if you all have any.
My current TODO list is:
Use PySNMP instead of the net-snmp CLI tools:
Better control over what's going on. Non-responsive routers seriously blow up my snmp script file. Calling an external script is..... ugly and I don't like it.
Add exclusions:
exclude tunnels, so say from dave to peter's Uppsala location, for example
mesh/hub/spoke:
The question of "do we do a full mesh or just a few hubs" has been moved in my mind from being a global question to an individual question. You will be able to choose if you want to be mesh connected or hub connected.
GRE/IPsec:
Dave hasn't responded to that email yet, but if he has in mind what I think he does I'm going to add code that is smart enough to setup an IPsec tunnel between locations if both ends support it and GRE if they don't.
Only update needed:
This one is WAY low priority but my plan is to make the code smart enough to only update routers that need it. For example: if Cory's IP changes his router config doesn't actually need to change but everyone else's does. If Dave's source interface changes his router config needs to change but no one else's does. This is seriously OCD/pedantic territory, but that's me. :)
-brian
