The content of this blog is my personal opinion only. Although I am an employee - currently of Nvidia, in the past of other companies such as Iagination Technologies, MIPS, Intellectual Ventures, Intel, AMD, Motorola, and Gould - I reveal this only so that the reader may account for any possible bias I may have towards my employer's products. The statements I make here in no way represent my employer's position, nor am I authorized to speak on behalf of my employer. In fact, this posting may not even represent my personal opinion, since occasionally I play devil's advocate.

See http://docs.google.com/View?id=dcxddbtr_23cg5thdfj for photo credits.

Wednesday, March 21, 2012

Focus on the focus window

I wonder if I should code stuff to bring the window I am working on the the center of my field of view, while moving other windows to the side. Again, related to more screens?

Shells tightly bound to directory?

I am noticing a pattern: I have long used emacs shell windows. But for some reasion more and more I am creating shell windows that are intended to be tightly bound to their directory. Whose name is their directiry. Where it gets confusing if I chdir in them. In fact, have had errors when I quickly type keystrokes to switch to a shell window command expecting to be in dir PROBLEM: had changed away from dir, deliberately or by accident I am beginning to wonder about DISABLING chdir in that sort of shell window. Or at least making it a bit more onerous. Why this is happening more now than in the past, I dunno. Possibly because I have more screens. --- Similar happens for xterms, but I use xterms much less often than I use emacs shell windows.

Understanding Exogenous shocks to Startups and Conditional Prophecy


    I remember first observing this when I worked at Bessemer. For example, there was a startup that supplied services to video websites. For years, the company soldiered along, barely growing. Then, suddenly, YouTube blew up and this company took off along with it. 

    As a founder, these exogenous shocks are out of your control, but you can 1) understand what exogenous shocks you depend on, 2) try to guess when those shocks will hit, 3) manage your runway so you survive long enough for them to hit.

This sounds very much related to my classification of prophecy or prediction:

There are 4 types of prophets:

(1) False prophets who are always or usually wrong, or are right by random chance. These are common.

(2) Accurate prophets, who can predict exactly what is going to happen, exactly when it is going to happen.  These are exceedingly rare.

(3) Eventual prophets, whose predictions, oft repeated, almost always eventually come true.  Here are some from the past, and some from the near future: "Computers will fit on your desk".  "Tablet computers will one day be popular." "Some day, computers will be worn, not carried, and will display on your glasses, contact lenses, directly onto the back of your eyes, or direct neural connect". Nobody with a clue will be surprised by the last set of eventual predictions coming true: the problem is knowing when, and how.  How to make it happen, and how to profit by it happening.

The final class of prophet is, I think, the most interesting, because it is sometimes attainable and more useful than anything except accurate prophecy:

(4) Conditional or contingent prophets:  they may not be able to predict exactly when something will happen, but they can make predictions about dependency graphs of events.  For example, referring to Chris Dixon's blog post "If internet video ever takes off (like YouTube eventually did) then there will be a market for video services for websites."  Or let me try: "Contact lens displays may take off (a) when nearly transparent pixels dense enough to be circa 1Mp on the size of a contact lens can be achieved, (b) when signals (whether by wire or non-wire (not necessarily electromagnetic wireless) can draw (not refresh) such pixels on a device, and (c) when a standby device <0.1W powered by energy harvesting can always run, and wake up a more power huingry device when needed).

When I helped start Intel's Microprocessor Research Lab I created several such dependency graphs.  Note: not just simple chains, since there may be more than one way at arriving at a result.