[DMcCunney]

Originally Posted by Dngrsone

Not really. I mean, as I said, one terminal. The computer was being used to operate an array of test equipment. There were a handful of subroutines that had to be running in the background (we're talking tens of individual components ranging from power supplies, measurement devices and switching to link it all together, using a half-dozen communications busses), but in the end, thre was only one user on the computer at any particular time.

There may have been only one user, but there was more than one job. Those background routines were started by something. On a *nix system, the something will be a system ID like root or bin which will be considered the user. I don't know how the Harris box did things.

I'm thinking that Harris found an excuse to offload some excess inventory and still fulfill their contract.

If this was a government contract, no surprise. The contracting officials will release an RFP, vendors will bid on the contract, and the winner will do what the RFP calls for, but it tends not to specify how it is done, only the results desired. If the vendor can unload gear while staying within budget, so much the better. (And in some cases, vendors will submit an unrealistically low bid to win the contract, assuming they can go back to the well for more funding, because it's easier for the contracting agency to give them more money than to fire them and have a different contractor restart from scratch.)

Same here: there was a card reader interface, and theoretically there were card readers available (actually in one facility there was one on-hand, just not in my shop), and our software programs were written and structured for storage on punched cards, but really...

The card reader in my shop was for the odd emergency where a job might need to be loaded from a card deck, but I never heard of it getting used. Even though storage and structure was for punch cards, the cards had gone virtual.

One of my instructors for the bench told us that our job (the one we were studying for) was a Cold war relic: should there be an nuclear blast (and accompanying EMP) that wiped out the data on our removable discs (those aforementioned 18" platters), then they could send out a card reader and stacks of cards and we could recompile all our programs and get running again. It sounded logical... in a Hollywood kind of way. Realistically, though, if the EMP were enough to penetrate several feet of steel to get to our platters and wipe them, then all the electronics in the entire test station would be crap, so they'd be shipping an entire bench or two, plus the software discs take up a lot less room and weigh less than an equivalent amount of punched-card data.

There are similar notions embedded all over. The Internet and TCP/IP had roots in a DARPA project to create a distributed fail-safe network that could route around failed nodes. The assumption in the Cold War times in which the initial design was done was that a node might fail because it had been the target for a nuclear strike.

I've seen doomday comments on the effects of Google going down, and all I can say is "If a disaster of a magnitude to put all of Google down occurs, being unable to reach Google will be the least of your problems..."

More likely is that Harris sold the card reader module with the computer or sold the government on the necessity to get rid of some of that excess inventory.

Might not have been excess inventory. But if your business is in part selling hardware, and you can sell some to the government, you do so. For all I know, having an actual card reader "just in case" might have been a contract requirement.

Hahaha. Yeah, I learned a lot more than most because when one of our guys left the shop he slipped a little something into the benches to mess with us: whenever someone loaded up a specific program (for the easiest thing we had to work on), the bench would essentially tell the tech to quick cherry-picking and go work on something important.

It took a little research, but I finally figured out and found the script he wrote. It resided on the system disc and since the system disc would be searched before the removable drive, his script would execute first. The script was basically print message, go to removable drive and execute.

I saw tricks like that played on the IBM system.

It's the same as substituting a custom script for an actual bash command by placing your script in a higher-priority directory.

If the system is properly set up, you can't do that. Among other things, scripts have absolute path names specifying the name and location of the interpreter that will run the script as the first line in shbang format, like "#!/usr/bin/perl", and if the script is running an external command, you can specify it by name and location. And if you're smart, you explicitly set $PATH in your script and include only the default system directories, so someone can't substitute something malicious with the same name that lives elsewhere. Unlike MSDOS and Windows, *nix only looks in the defined PATH when you specify a command to run. They do not look in whatever the current directory happens to be first the way DOS and Windows do. To get them to look in the current directory at all, you must explicitly add "." to your PATH, but you add it as the last entry so the system dirs all get searched first.

Exactly. The hack is basically exploiting a vulnerability on the modem and running commands as root, then using its nsh console to set it to true bridge mode, which is not possible through the public shell, by redirecting the PPP stream through one of the ethernet ports. reference

<sigh> A decent modem/router shouldn't require you to exploit a vilnerability to do that. It should be an option in the administrative interface.

Been there, done that: Palm T|X for close to eight years before I was forced to use a 'smart' phone.

This wasn't a TX. It was a Tapwave Zodiac 2, and you could get a Wifi SD card to plug in to get it on line. That card only supported WEP.

The TX had a firmware update from Palm that added WPA authentication, and mine has it applied, but I've never been able to get it to connect to my router.

Going online with the Zodiac was mostly a "because I could" exercise, used seldom. (I did test that I could SSH from the Zodiac at home to a *nix server in the office, but I dreaded having to actually do it for anything serious.)

Right. The onion routers remember where your machine is and route packets accordingly (I'm being overly simplistic, I know). Is this not the same as network address translation? I mean, my router remembers where my machine is at and routes the packets that belong to it accordingly... as far as AT&T knows (in my case), all data is being requested by and sent to one single IP, the router. It's the router's job to figure out which packets belong to my machine and which belong to the Playstation, or to the television.

I suppose you can think of it that way. When you send a TCPIP packet, the packet header has a source IP and destination IP address. If you use Tor, you don't want your real IP address so Tor diddles the packet headers internally. The idea is that the system you connect to doesn't know the true origin of the traffic and can't find out.

On a home router, NAT is used to have multiple devices behind your router connect through one public IP. The router maintains connection and state information, so it knows what packets coming back are intended for what device in the internal network and can pass them along.

I certainly will do so.

I look forward to it.