When I was a grad student at Stanford I thought the idea of virtual machines was entirely crazy. And then came cloud computing.
This CACM article nicely summarized the background story.
2020-04-04
Virtual machines
2018-12-11
Lytro
The light field camera is a beautiful technology, but consumers find it no more useful than 360 imaging.
2018-08-26
Git research source
Below is a summary of my suggestions of using git to manage research source, based on numerous discussions I have had with my collaborators across multiple projects at multiple institutions.
Always revision control your code. There are multiple options, but at this moment of writing, git beats alternatives such as svn and perforce.
Use github for public repos and bitbucket for private repos.
Start with existing code if feasible. If the code is already under git, use submodule as a component or fork/branch as an extension. Otherwise, convert the code into git, and preserve revision history whenever possible (e.g. github/bitbucket can help you convert svn repos into git repos).
Use multiple branches for different versions of the code, such as stable branch for release or a personal branch for experiments.
Use multiple remotes across organizations and time-frames.
For example, during your internship with a company, use an internal corporate github repo, and sync it with an external bitbucket (private) repo at the end of your internship so that you can continue the project at your school. When you are ready to publish your code, mirror it to a public github repo.
Keep multiple remotes under the same repo for easy management.
For paper drafts, you can create an overleaf git branch for more WYSIWYG-style editing while retaining all the benefits of branching and revision control.
Keep one (or at most a few) sentence(s) at one line, to avoid false alarms from spell checkers (broken sentences) and excessive (line-based) diff by git.
Note that Latex treats line breaks as spaces.
Chongyang Ma (@ Snap Research) has recommendations for industry research code practice.
2017-08-28
git obliterate
At the end of trying out BFG to purge a large compiled file from a repo, the following message was displayed:
π
—
You can rewrite history in Git – don’t let Trump do it for real!
Trump’s administration has lied consistently, to make people give up on ever
being told the truth. Don’t give up: https://github.com/bkeepers/stop-trump
—
So with git, one no longer needs to be a rhetor to change the past.
2017-06-02
I wonder how many people truly find the user experience compelling or merely stay put because all their friends are there.
2017-02-24
F*** you money
2016-11-12
Basis cases
Back in the good old days when I was working as a GPU architect in NVIDIA, we had suites of tests for various stages of GPU development: architecture, RTL, driver, real chips, etc.
Ogtest, consisting of tests written in OpenGL, can be applied to all stages. Each test is written to be as compact as possible, the tests are ordered from simple to complex, and collectively they cover the entire target space (e.g. all applications to run on the target GPU).
For example, the first test is to draw a flat colored triangle, the next is a textured triangle, and the next is called son-of-the-textured-triangle (with two textures instead of just one, if I remember correctly).
I then went on to add a test called daughter-of-the-textured-triangle (I am all in for gender equality) which consists of two textures but exercised a different path through the texturing and shading units (if I remember correctly).
I like to think of these as the basis test cases for the entire target space, analogous to basis vectors in linear algebra.
This applies to all research and development projects. Instead of jumping to debug full-scale applications, it can help to design a set of basis cases first. The process can clarify our thinking, and help us debug and explore algorithm/implementation issues. The basis cases can even be part of the analysis section of a research paper.
2016-08-19
svn to git migration
In the process of migrating some svn repos on my server to git repos on github (public) and bitbucket (private), I found the following migration process works well.
. Import the svn repo to github. It worked for private svn repos that require authentication (as in my case).
. The github repo will be public. If you want a private repo, import the github repo to a private bitbucket repo, and delete the public github repo.
I looked at the revision history and it appears to be well preserved.
I have tried direct import from svn to bitbucket but it did not work, probably due to file system structures of my svn server.
