Zero Knowledge

Kim Zetter has written the definitive story -- at least so far -- of the possible backdoor in the Dual_EC_DRBG random number generator that's part of the NIST SP800-90 standard.

Pixar’s 22 Rules of Storytelling by DinoIgnacio.

From the webpage:

Former Pixar story artist Emma Coats tweeted this series of “story basics” in 2011. https://twitter.com/lawnrocket These were guidelines that she learned from her more senior colleagues on how to create appealing stories. I superimposed all 22 rules over stills from Pixar films to help me remember them. All Disney copyrights, trademarks, and logos are owned by The Walt Disney Company.

If you find the rules hard to read with the picture backgrounds (I do), see the text version: http://imgur.com/a/MRfTb.

While cast as rules for “storytelling,” these are rules for effective communication in any context.

Easy 6502 by Nick Morgan.

From the post:

In this tiny ebook I’m going to show you how to get started writing 6502 assembly language. The 6502 processor was massive in the seventies and eighties, powering famous computers like the BBC Micro, Atari 2600, Commodore 64, Apple II, and the Nintendo Entertainment System. Bender in Futurama has a 6502 processor for a brain. Even the Terminator was programmed in
6502.

So, why would you want to learn 6502? It’s a dead language isn’t it? Well, so’s Latin. And they still teach that. Q.E.D.

(Actually, I’ve been reliably informed that 6502 processors are still being produced by Western Design Center, so clearly 6502 isn’t a dead language! Who knew?)

Seriously though, I think it’s valuable to have an understanding of assembly language. Assembly language is the lowest level of abstraction in computers – the point at which the code is still readable. Assembly language translates directly to the bytes that are executed by your computer’s processor. If you understand how it works, you’ve basically become a computer magician.

Then why 6502? Why not a useful assembly language, like x86? Well, I don’t think learning x86 is useful. I don’t think you’ll ever have to write assembly language in your day job – this is purely an academic exercise, something to expand your mind and your thinking. 6502 was originally written in a different age, a time when the majority of developers were writing assembly directly, rather than in these new-fangled high-level programming languages. So, it was designed to be written by humans. More modern assembly languages are meant to written by compilers, so let’s leave it to them. Plus, 6502 is fun. Nobody ever called x86 fun.

I’m not too sure about no assembly language in your day job. The security on Intel’s Ivy Bridge line of microprocessors can be broken by changing doping on the chip. Not an everyday skill. See, Researchers can slip an undetectable trojan into Intel’s Ivy Bridge CPUs by Dan Goodin for the details.

I mention the 6502 ebook because programming where subject identity is an issue is different from programming where all identities are opaque.

Think about calling a method on a class in Java. Either the runtime finds the class and method or fails. It does not look for a class with particular characteristics and if it passes a subject identity test, then invoke the method.

I mention this because it seems relevant to the scaling question for topic maps. When you are manipulating subject identities, there is more work going on than invoking opaque strings that are found or not.

Part of deciding how to deal with the additional overhead is choosing which subjects are treated as having identifiers and which are going to be treated as opaque strings.

By Ian Cottam, IT Services Research Lead, The University of Manchester.

This is the first in a series of blog posts on my heroes of software engineering. I hope you will find it (and subsequent ones) of interest.

# 1 – Welsh and Quinn

My first heroes are Jim Welsh and Colm Quinn. Why? Because their 1972 paper [1] was the first one that convinced me that there was a discipline worthy to be called software engineering and that what they did was a tour de force, leaving me open mouthed in admiration of the magic they had dared to conjure.

read more

A team of scientists at USC has verified that quantum effects are indeed at play in the first commercial quantum optimization processor.

The session schedule for this week’s //build/ conference in San Francisco has now been posted.

I have a talk on Friday at noon Pacific time, titled “The Future of C++.” Note this is a Microsoft conference, so the talk is specifically about the future of the Visual C++ product, but nevertheless it’s all about Standard C++ because I’ll start with a short update on ISO goings-on and the bulk of the talk will be an update on standards conformance in Visual C++ and explaining a number of the most modern ISO C++ features.

On Friday, you can watch my talk live at Channel 9. In the meantime, you can get the keynotes and some other major sessions at the same link all day today, tomorrow, and Friday… as I write this, a cool guy named Steve has the camera and just gave away thousands of nifty 8″ tablets. I’ll be in the same place in two days to talk C++.

If you’re in San Francisco for //build/ and care about C++, you want to be in South Hall: Gateway Ballroom for session 2-306.

If you’re not at the conference but use Visual C++ as one of your C++ compilers, you’ll want to watch the talk live in the webcast or on demand about 24-48 hours after the talk ends.

Even if you don’t use Visual C++ a lot right now, you might find some of the ISO C++ standards context and updates interesting.

Stay tuned.

Filed under: Talks & Events

Unlike many programmers, I actually prefer to use one monitor these days. A lot of my colleagues have Visual Studio filling the entirety of their primary monitor and either Outlook or documentation filling the other, often with a bunch of other apps like Lync, a command prompt or two, and likely a music player.

When I moved to Microsoft HQ about 5 months ago I found that my new PC was lacking a second HDMI output and I didn’t have a DVI-VGA converter for the second twenty-something inch monitor I’d been given. Weirdly, once the part arrived a week or so later, I went to plug it in and… found that I didn’t want to.

A single monitor really cut down the distractions. I get a lot of mail – a lot of mail – and the constant flood of it in the corner of my eye was becoming a problem. (I have to add that turning off the task-bar’s “New Mail” icon in Outlook also helped a lot.)

Since I cut down to a single screen, my ability to focus has increased dramatically and that my primary monitor is easily big enough for code and documentation if the need arises. I actually prefer having the documentation right there, next to my code, rather than having to flick my eyes over to another monitor.

When I need to “dual wield”, I use the little known Windows key + Arrow keys hotkeys. If you’re unfamiliar with these, give them a try. Windows+Left and Windows+Right are by far the most useful, as they will:

• snap the window to the left or right half of the screen,
• flip the window onto the next monitor if you have one.

Windows+Up will maximize, whereas Windows+Down will restore or minimize depending on the window’s current state.

After about 5 months of using them, these shortcuts are now indispensable. However, they weren’t quite useful enough. A common scenario is that I just want a little more than half the screen for code, as documentation pages tend to deal well with smaller browser sizes. Or, sometimes I have a command prompt pinned to the right, but I have to fiddle about with the mouse to fill the gap because command windows won’t generally expand horizontally.

Another problem was stacking windows above each other. In an ideal world, VS would occupy 60% of the left side of my monitor, and on the remaining right side, I’d have documentation taking 70% of the top right corner and the command prompt in the bottom right 30%. With the vanilla Windows hotkeys, this is impossible with keyboard alone.

And thus, my answer to this was to write code, culminating in this: Advanced Window HotKeys. This is a tiny app that will run in the background, and using the Alt+Arrow keys (among others) will net you some really fine-grained control over your window layout. I went one step further and the tool will also help you preserve your current layout but still allow you to resize the foreground window, moving other windows out of the way. Check out the page for more information.

I wrote this in VS2012, C++ and Win32. Win32 really is a very powerful API. This tool makes extensive use of EnumWindows and MoveWindow to expand or contract the foreground window; search for adjacent windows to snap to; modify adjacent windows to prevent overlap;and other stuff. I threw in a little Control Panel, although that’s still very primitive.

I haven’t tested this on anything other than Win8, so if anyone wants to volunteer to see how this’ll work on Win7 or below then please comment or email me. I’d really appreciate feedback, so you can do that using the email link at the bottom of the AWHK website.