I don't think anyone in the Patriot Guard Riders would object to widening the scope to include kids funerals the WBC protest.

I know I have to agree with the general sentiment.. There are some lines you just don't cross. Picketing a 6yo's funeral is a few hundred miles beyond that line.

Try RTFA:
>Not this phone. It sat by the cash register unclaimed all the next day. “I don’t know anything about this stuff, but I know enough to know this phone was different.”

So the phone sat in the bar for a day and then they tried to figure out who owned it. Sounds pretty reasonable to me.

A better parallel is a phone number.

Somebody made a phone call with a voice distorter and threatened someone.
That phone call came from your house. Should you be arrested and thrown in jail because of that?
Or do they have to prove it was you that made the phone call?

We do own the contents of deployment but not the mechanics of deployment. That means we setup software into packages the deployment system can consume. We identify what set of packages goes into an environment. We choose which environments go on which hosts. The actual deployment is kicked off via a web UI.
The merchanics of the deployment then worry about copying the data over and running the deployment scripts.

If something goes wrong with the automated system it is someone elses problem. However if something goes wrong with the scripts in the package we are deploying it is the devs problem.

I've been in companies that practiced it both ways.

Company A) Developers can never ever access production no matter the reason. The end result in that situation was bugs that couldn't be reproduced on the desktop or in the QA environment. The problems went on for months until I had a lucky break of a developer moving jobs into the system admin role of the production environment. When he looked things over he discovered the previous admin had not configured things in production properly. To the point of lying about it when I had sent a previous check list of things to verify. If I had access to the systems the problem would have been resolved in a few days rather than months.

Company B) Developers own the software and hardware from end to end. In my current company we have to package the software up into a deployment system and deploy it that way. However we do have full access to all the systems. Can/do we do hacks and quick fixes? Yes, if the situation warrants it. But in the end it has to get rolled into the official distribution for it to be correct. Can it be abused? Yes. But that is why the culture of the company become very important. In the end you either trust your developers to do the right thing or you don't. If the company can't trust the developers to have ownership of their code and systems.. Well then at least for me I would say I'm working at the wrong company.

FYI, I enjoy working at company B far more than I ever did at company A. Given a choice I will never go back to an environment where developers don't have access to production.

On the C64 you had to move the ROM out of the way to get to the RAM underneath. I don't remember the exact details but you could either see the RAM or the ROM and it was controllable.

If you want to get into memory expanders the C64 had at least a 512K ram expander available. I remember having one and it worked with GEOS at least.. might have been used as a form of ram drive to speed up games as well.

The drive drive was a computer in itself that you could buy ram expanders for and run programs on. Typically used for increasing load speed or duplicating copy protected disks.

You do realize the Kindle reads PDFs as well.

I have a Kindle Keyboard (Wi-Fi) and all I have to do is copy the PDF over into the documents folder via the USB cable.

He is the Chairman of the Board and was representing the company during the annual shareholders meeting.
That doesn't fit the whole he doesn't really work there anymore statement.

When he isn't on the board and isn't representing the company at the shareholders meetings I'll believe he doesn't work there anymore.

You hit the nail on the head. The primary reason for that is once you have someone hired it is exceedingly hard to get rid of them. You only have to be burned badly once before you only want excellent candidates instead of good enough candidates.

Yes because that couldn't be exploited at all..

What's that? The malware/trojan/root kit installed it's own root-certs and is running a proxy listening on 127.0.0.1:80 and 127.0.0.1:443?
That proxy is snarfing up all the data and shipping it off to some other server...

Just because you can't imagine how it could be abused doesn't mean it can't be abused.

No not forever.. The record so far is 14 years http://en.wikipedia.org/wiki/H._Beatty_Chadwick

John Titor would be the person to help you out with that.