how will Xerox ever recover?

yet another vulnerability caused by mental midgets who were taught to program in BCPL! this could have been avoided if we wrote everything in Rust

http://www.righto.com/2018/01/xerox-alto-zero-day-cracking-disk.html

this could have been avoided if we wrote everything in Rust

Would it?

>>2
Yet, it would. It says so in >>1.

>>2
not really, I was obviously being sarcastic. actually I'm parodying that one guy who used to spam this board blaming 'C mental midgets' on every vulnerability ever, as well as typefags who think that type systems 'solve' security.

>>4
Type systems solve one kind of problem allowing the brain to focus on other problems.

>>5
b-but muh Hurry Coward

Chekc my dubs

>>7
ERROR: Invalid dubs

>>1

I'm flabbergasted. That's my Alto disk you broke into!

The APL stuff is surely related to some work I did with Leo Guibas, showing why lazy evaluation would be a really good idea for implementing APL: see Compilation and delayed evaluation in APL, published January 1978. (That paper gives me an enviable Erdős number of 3, since Leo is a 2.) I'm sure it's not a complete APL implementation, just a proof of concept. It happens that my very first part-time job at PARC, in 1973, involved writing decision analysis software in APL -- on a timesharing system!

Given the AATFDAFD hint, I'd guess the real password is ADDATADFAD. This derives from a project I did with Jef Raskin at UCSD in 1974. (He mentioned it in this interview.) The Data General Nova we were working with produced some garbled message with ADDATADFAD where it should have said ADDITIONAL, and it was a running joke ever after. Strange, the things that occupy some brain cells for over 40 years.

Thanks for an amusing blast from the past.

-- Doug Wyatt (Xerox PARC 1973-1994)