David Griffith <dgriffi at cs.csubak.edu> writes: I have never seen one on eBay - and I have looked often. Found a lot of other things that are named VT52 though... -Ian

On 3/8/07, Chuck Guzis <cclist at sydex.com> wrote: Dunnou about David's needs, but for my own (VTEDIT under OS/8), emulation within a more modern dumb terminal is rarely accurate enough. If you just want approximate emulation, lots of DEC terminals and DEC-compatible terminals do offer VT-52 emulation, but I've only tested and rejected the emulation in the VT220. -ethan

On 3/8/07, Dave McGuire <mcguire at neurotica.com> wrote: The TECO macro "vtedit.tec", in various flavors, was used to simulate a visual editor by chopping up bits of the file being edited and slinging them around on the screen with TECO as if you were using something like EDT or vi or whatever else you think of when you edit text in a more advanced way than a simple line editor (like 'ed'). I don't recall off the top of my head how to invoke it, but essentially, you'd fire up TECO in a way so as to drag your file (or a blank file) into the edit buffer, then get TECO to execute the VTEDIT macro on the buffer, letting you walk through the file, make changes, save it, etc. There are a number of TECO macros here... http://mvb.saic.com/freeware/vax88a3/tecoc/ The one called 'vt52.tec' looks interesting. I used to have a keymap printed out and taped to my VT52 that looks a lot like the grid embedded in this file. I never could read TECO macros by glancing at them, so I'll defer to others on how it all works at the bottom layer. I could do simple stuff with TECO, but mostly relied on vtedit.tec working correctly to get any "real" work done under OS/8. Thinking about this all, I should fire up my SBC6120 with my IOB6120 and see how well the VT52 emulator in the IOB6120 FPGA works. For those that don't know the hardware I'm describing, the SBC6120 is (was?) a 12-bit single-board micro based on the IM6120 microprocessor (PDP-8/e-like), and the IOB6120 was an FPGA-based peripheral for it that gave it 3 more serial ports, a 2MB RAM disk, a printer port, and an emulated console VT52 (with VGA output and PS/2 keyboard input). If the VT52 emulation isn't good enough, all the code is available for me to improve it. I just have to learn VHDL first. ;-) -ethan

In article <f4eb766f0703081416l4928f0fv5d75f3ba02050b5 at mail.gmail.com>, "Ethan Dicks" <ethan.dicks at gmail.com> writes: Working on it, but don't know how I would haul them out there on any reasonable budget. I'm talking with Sellam, but appears *I* have more interesting terminals than he does! I remember seeing one in 1979/1980 and the bell was described to me as "grinding the gears on a 1952 Chevy" :-). Even bona-fide VT100s are scarce. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>

That 'Bell', is astually a relay that's driven by a square-wave signal make a buzzer). The same relay, fed with a pulse generates the keyclick. There are 3 or 4 here, along with a VT105. I don't have a VT52, though. I do have a VT55, does that count ? :-) -tony

On Mar 8, 2007, at 1:24 PM, David Griffith wrote: I'd love to know myself. I've wanted one for *years*, but I've never found one. Hell, I can't even find VT100s anymore. About ten years ago you couldn't walk down the street without tripping over VT100s. -Seth Santa Clara, CA, USA

Actually the Double-Height/Double Width is one of my main problems, flashing less so. IIRC, once I upgrade to Mac OS X 10.4.8 (I'm on 10.3.9), this will be at least partially taken care of. This isn't as much of a show stopper for me though as the application keypad not working right. I make heavy use of the keypad, and can't live without it. I would like to be able to use all of the function keys. Zane

The keypad emulation is the very first thing I check when trying out a new emulator. Then I look at double-high/double-wide. If I could find one that handled both of those things *AND* screen display on my Mac properly, and didn't require a mortgage, I think I'd pass out from shock. My favorite is the LK401, it's fragile, but I like its feel, even if it is a bit mushy for my tastes. But then my favorite terminal is the VT420, though I'm running the one on my PDP-11 with a LK201 keyboard. I'd like to pick up a VT525, with a good keyboard (I assume it would be a LK450 or some such). The VT525 looks like a DEC Multia, can use a PS/2 keyboard, and will work with at least some LCD panels. Both Compaq and HP have released some "thin-client" terminals running some form of WinCE. They look rather interesting, but I don't know how good the terminal emulation is. Last I checked, you can still buy VT520's from Boundless (they bought DEC's terminal business). Zane

At 9:00 PM -0500 3/8/07, Dave McGuire wrote: I honestly have no idea, I have assumed they did the VT520 and VT525's themselves. I've used some VT520's, and my primary complaint has been that they typically seem to have come with PC keyboards. Rather worthless when you need to get into the setup menu! Though considering they came with Auspex fileservers this might have been done on purpose to keep people out of the menus! The VT520's didn't seem that bad to me, but then I haven't used one on a DEC system, so wasn't coming close to taxing their capability. Zane -- | Zane H. Healy | UNIX Systems Administrator | | healyzh at aracnet.com (primary) | OpenVMS Enthusiast | | MONK::HEALYZH (DECnet) | Classic Computer Collector | +----------------------------------+----------------------------+ | Empire of the Petal Throne and Traveller Role Playing, | | PDP-10 Emulation and Zane's Computer Museum. | | http://www.aracnet.com/~healyzh/ |

On 8 Mar 2007 at 17:04, Zane H. Healy wrote: Do the collectors of VT100/VT220-type terminals collect mostly DEC equipment? I seem to recall that the Televideo 922 and the Tab (I'd have to look for a model number) were very decent terminals and may have had good VT52 emulation. When I worked with a VAX 11/750 back in the 1980's, I recall that the sales guy (not DEC, but an independent) preferred a non-DEC terminal with a nice 14" display. VT100/220 type terminals were pretty big business back then and many manufacturers made them. AFAIK, they all developed their own code. Cheers, Chuck

It aws, once upon a time. But these days, it uses ./configure, which is a security nightmare waiting to happen. When I wrote to the author about that, the reaction I got back was basically "tough" - I suppose he feels that his convenience outweighs the security of our systems. Perhaps it's time to mention mterm again. It's my terminal emulator for X, and it has a "decansi" emnuation that's X3.64 with some DEC extensions. decansi mode running at 80x24 (or 132x24 - it will try to resize its window if you send the column-count change sequence) is a pretty good VT-100 emulator. I mention it here because it does DH and/or DW (including single-width double-height, which VT-100s don't do). It's slow the first time you use it, because it has to take the character glyphs and magnify them, but once a character is magnified, that character is tolerably fast. If your keyboard has the keys, and you have them mapped to the correct KeySyms, I think mterm doing decansi emulation gets them right. If you find any respect in which it doesn't, I consider it a bug (though I may reclassify it as "misfeature" if it proves too hard to fix :-). See ftp.rodents.montreal.qc.ca:/mouse/X/mterm.src/ for them as wants. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse at rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

No (well, not most of them); why? Do you think running malicious code is fine provided you're not running as root? As I wrote, I'm sure there's some fancy-schmancy URL syntax for anonymous FTP areas, URL:anon-ftp:somethingorother or some such. I prefer to stick to the good old host:pathname syntax used for anon FTP since ~forever. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse at rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

None...probably. The thing is, configure is an excellent place to hide a malicious grappling hook: it is frequently run by na?ve installers, not uncommonly as root; by the nature of what it does, it is hard to sandbox (for example, it *must* be able to compile and run new programs); it is large and comparatively difficult to read over for human verification. This means that unless I take an hour or two and read through configure, I'm basically betting the security of my system that the distribution didn't get trojaned. Even if I *do* take that hour or two, reading configure is mind-numbing enough that it's easy to miss something subtle. (I've read through a couple of configure scripts.) I've thought about how I'd go about trojaning a configure script, and the answers scare me enough that I have to want something quite a lot before I'm willing to "just run ./configure". This is why I called it "a security nightmare waiting to happen". As interested as I am in how mterm -termtype decansi stacks up against vttest, I'm not nearly interested enough to be willing to either take that risk or take that boring couple of hours (still leaving some slight risk). /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse at rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

Yes. But it's substantially easier to verify a program than a configure script. For example, if any of the .o files making up vttest were to refer to socket() - something easily checked with nm|grep - I'd want to at least look at the code for it. That sort of verification is substantially harder to do for a configure script. I'd also point out that this is hardly distinctive to open source; running closed-source binaries involves the same trust only with a significantly lower ability to check even if you wanted to. Oh, I'm much less worried about one of the overt authors. I'm more concerned about some malicious cracker breaking into the distribution mechanism at some point and inserting something malicious that the legitimate code authors didn't intend. (I've already heard of it happening at least once and I think twice.) Speaking purely personally, this is also part of the reason I tend to roll my own so much - though that isn't much help to other people faced with the same dilemma. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse at rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

In the old days... with rn or perl etc... the stuff was posted via the Usenet and through comp.sources.unix -- so I knew it had lots of eyes checking it, uudecoding it and building it. Any idiot can put something out in an email now as an attachment or on a website. The problem is you used to trust people more because the net was less open and more a group of folks with shared interests. There were a lot less of the hacker dudes out there looking to do the digital equivalent of tag my site with graffiti. I regularly gave out access to my personal machines including root to folks I trusted. Telnet access, uucp access. No ssh. The slow speed meant that there were few dial-up dictionary attacks. Most of the locals knew each other by reputation. It's a much uglier world out there. Bill On 3/9/07, Richard <legalize at xmission.com> wrote:

The point is in the old days the distribution was source code that would be submitted by an author and approved for publication by the group moderator. That's a lot better than unverified attachments -- especially binaries. As for the ./configure -- at least you could go through the source code and see what it was doing. Bill On 3/9/07, Richard <legalize at xmission.com> wrote:

On Mar 9, 2007, at 2:44 AM, der Mouse wrote: Well, "Fine", no...but certainly not particularly dangerous if you're doing it under a dedicated account and your machine isn't swiss-cheese security-wise. And it's certainly no more dangerous than anything else and running it without inspecting every line of code. (I missed that somehow) Sounds good to me, I do the same thing. :-) I will grab mterm and check it out. -Dave -- Dave McGuire Port Charlotte, FL

Rumor has it that Dave McGuire may have mentioned these words: Of course I do -- doesn't everybody??? I always log in as root on my laptop -- I don't think I have a non-root ID on the thing unless it's for a daemon and has no shell. I also don't re-alias mv to 'rm -i' or cp to 'cp -i" either... I also try my best to not do anything stupid (like let anyone else touch the computer ;-) -- and the only time I've been burned is when I didn't try hard enough, and did something stupid. What I don't like, is that if you set a file to read-only, root can still whack it. That's my WTF... OS-9 never did that! If it was read-only, even the SuperUser couldn't delete it - you had to manually set the attrib back to writable before you could delete it. That burned me once early on in my Slowaris educamation... =-=-= Bringing this back ontopic, in OS-9, is there a way to *not* be the SuperUser without logging in externally? Whilst trying to get Rogue to not delete it's savefiles, I tinkered with the idea of setting either the Rogue process to non-SU mode or the files themselves to non-SU mode, and never had a lot of luck; it intrigued me so much that I kept tinkering with the idea for a few _weeks_ after I realized a few hours into the project that read-only meant exactly that even for the SU. Never really did get very successful with it... Logging in externally (with my Model 200) was easy to see different owners' processes in procs, but never could do it from within the SU id... Maybe I was just "forking" stupid there, too. ;-) Laterz, Roger "Merch" Merchberger -- Roger "Merch" Merchberger | A new truth in advertising slogan SysAdmin, Iceberg Computers | for MicroSoft: "We're not the oxy... zmerch at 30below.com | ...in oxymoron!"