It's interesting to read about the debate between doing editing/screen-drawing on the physical terminal ('smart' hardware) and doing it all in software. The wheel of reincarnation in action! Something we've seen in tech constantly, the balance between local vs distant computing determined by bandwidth/latency... Lately, smartphones, desktops and VR or sound: should the processing be done in the headphone/headset or away in in the PC/smartphone?
I really liked the SUPDUP but that section describing it doesn't really get to the intense crockishness of the protocol. It really was ITS terminal control brought out over the network: the capabilities were the 36-bit terminal descriptors sent over the network in PDP-10 order.
DLW later wrote a different Emacs implementation in Lisp, Zwei, for the Lisp Machine, which was even more deeply intertwined in the system than Multics Emacs was in Multics. Zwei (Zwei was Eine Initially) followed Eine (Eine is not Emacs)
FWIW both programmers mentioned in that section, DLW (Dan Weinreb) and MRC (Mark Crispin), died relatively young.
How would you know if they have been? As the human population shoots up massively, car-miles have increased enormously over the past century, and rural areas become denser, the number of deer-car accidents would skyrocket even if they have successfully been evolving to reduce risk.
The obsession with information theory here seems like a classic nail-hammer thing. The number of bits my tests convey is totally useless to think about and certainly not worth spending pages on. All I want from my tests from a code base I maintain for thousands of patches is a tiny fraction of a bit: did my latest change break an important behavior or invariant encoded in a unit test? If I only screw up once in every 100 patches, then formally, my unit tests are doing all that work to emit 0.01 bits of information (-log(99/100)), which is formally a totally irrelevant thing to know about my unit testing framework. ('Hey Joe, what have you been up to?' 'Fixing my unit testing framework - I'm up to 0.03 bits per patch!' 'I see.')
This is perhaps the stupidest and most hysterical thing I've ever read on Stross's blog. I don't think I need to explain why Brexit is not going to lead to the https://en.wikipedia.org/wiki/European_Potato_Failure and a million deaths from starvation.
You can definitely see where this is going. My first thought was the same: 'we need eyetracking for foveated rendering anyway, so we can get realistic eyes for free', and if you can do that, you can track the eyebrows and muscles around the eye (doesn't need great fidelity), and I wonder if that gets you all the way to the rest of the face as well? Can you smile/frown without it tugging on the parts closer to the eyes which the future headsets can observe?
"Experts said it was likely that the NSA or FBI had approached other Internet companies with the same demand, since they evidently did not know what email accounts were being used by the target. The NSA usually makes requests for domestic surveillance through the FBI, so it is hard to know which agency is seeking the information.
Reuters was unable to confirm whether the 2015 demand went to other companies, or if any complied.
Alphabet Inc's Google and Microsoft Corp, two major U.S. email service providers, did not respond to requests for comment."
It's not a hard question to answer. You either are or are not searching all emails in realtime at the behest of the NSA.
They later responded. Quoting from Arstechnica's 5:11 ET update:
A spokeswoman for Microsoft, Kim Kurseman, e-mailed Ars this statement, and also declined further questions: “We have never engaged in the secret scanning of email traffic like what has been reported today about Yahoo.”
For its part, Google was the most unequivocal. Spokesman Aaron Stein e-mailed: "We've never received such a request, but if we did, our response would be simple: 'no way.'"
How much trouble would someone like Google be in if they gave a "warrant canary" style answer? "I'm sorry, we are unable to answer your question" would speak volumes without actually saying anything.
But I suppose that the order forbids "disclosure", and that statement is arguably disclosure...
> If you think the Internet is as safe and controlled as a shopping mall, you probably should be reading Krebs on Security more.
That's an amusing comparison, given how much of Krebs focuses on offline ATM skimming, copying credit cards at point-of-sale terminals, hacking major retailers's CC databases, and using stolen cards at retail and mall stores to cash them out...
You could probably apply the same code. The dataset ("acquire 75,471 sketches of 12,500 objects") sounds adequate, and if not, can be boosted by first training a CNN to do photo->sketch (throwing away information is usually easier than imagining it) and using that to boost the dataset for sketch->photo.
> All of those goals are achieved with its design and improving on this foundation is certainly possible. These were all hard problems to solve at the time, given the state of the art was CVS, subversion and perforce.
The state of the art was not CVS, Subversion, and Perforce when git had its first release in 2005. The state of the art was BitKeeper (which you might remember had a certain connection to Linus and git), Arch, Monotone, and Darcs, and Mercurial itself was first released almost simultaneously with git. And one can debate the extent to which git was an improvement on any of those on key features like cryptographic signing or UI/UX.
