An adventure with qemu

I tried to install Windows XP with qemu. It installed successfully. Starting XP up for the first time, the monitor went idle and would not recover. I restarted the machine. Kernel panic. A subsequent reboot left me with no display. My steps to recovery:

  1. Crack open “Absolute OpenBSD” and grab the serial cable. I can do this.
  2. Remember I have no machines with serial ports.
  3. Reseat RAM and reboot. No display.
  4. Shove RAM into another slot and reboot. No display.
  5. Remove CMOS and replace. Reboot. No display.
  6. Order $400 worth of parts for a new computer, cancel, and then order a quad-core CPU. It must be the processor, because I don’t know.
  7. Try a second, known-good monitor. No display. Assumption: bad VGA port.
  8. Purchase a GPU and test the VGA. No display persists. Rule out bad VGA port.
  9. Sit in consternation.
  10. Take out the CPU and turn on the machine, just for giggles. Observation: without a CPU, the machine doesn’t shut down while holding down the power button. Assumed conclusion: a working CPU signals the shutdown. Rule out defective CPU.
  11. Replace the CPU and purchase RAM.
  12. Install new RAM. Display works.
  13. Save the new CPU for a rainy day.

Windows XP installation instructions provided by Cromwell.

Be the tide

I was afraid that my code emitter would put me out, because I had democratized my job. Now anyone could write my scripts with a few clicks and some bit of knowledge. I was afraid, because I had not managed the right frame of mind.

The right frame of mind for this is that “a rising tide lifts all boats.” That is, do not be a boat among boats; be the ocean, the waters. My job is not to protect my job; as a programmer, I am a force multiplier. What I ought to will, if any truth, is to push forward skill so that others’ works are even better than before.

I am still worried, but less so. Fearful of losing, I let go first. Obsessed and paranoid to the point of selfishness, I wrote a tool out of selflessness. The only logical step from here is to mechanize the entire process; and like the ocean, we no longer worry about boats.

Built to last

For a command-line tool, I encountered the question of whether to display extended help or a synopsis first. For new users may appreciate the context, but experts only want a refresher. I realized then that we are novices but once, and experts after.

Well, the real truth may be that printing a synopsis is an easier stake in the ground than typing an essay on the tool’s philosophical motivations to exist. But it was interesting enough to cause pause: our audience is the eventual expert, not necessarily the neophyte; over time, you personally are getting better at using a particular piece of software, not getting worse – and certainly not forgetting everything to when you started.

There is also the legacy bit: the feel of a substantial program, and not just a proc to call. That it could be useful in other unimagined contexts by other users, much like the Unix text filters. It is easier to care when there are hard edges of convincing worth.

Being totally and complete wrong

One of my least favorite experiences is launching programs that only work on my machine, but distributing it under a heavy delusion: that it will work, somehow. I mean, the context is freewrap cannot run executables contained inside its virtual directory, period. Whatever convinced me of the possibility has finally come out.

Workarounds include copying it first and then executing it, which is the same as distributing the naked support executables themselves. I’m back to square one, at any rate. Using freewrap, then, is for the Tcl code only.

If I wanted to pick something to specialize in, it would be channels. Understanding pipes and asynchrony between them, would do wonders outside of threading. For once, event-driven programming and I are on the same page.

Beware UTF-16le

Be careful your source file isn’t UTF-16le: saving out a HTML file from cURL will yield that, and Tcl tDOM won’t be able to parse the tag tree. Perl offers a way to read in the encoding and then write out a sane file, but you can avoid that by just writing out to text from cURL. When even cygwin complains, there is something up:

test.html appears to be a binary file. Open anyway?

Similarly among the monks, here is the file printed from perl:

< h t m l >
 < p > a n  e x a m p l e  o f  t h e  w e i r d n e s s < / p >

Two-state solution

You can just use adb.exe without detecting USB events via AutoIt. There are two instances when Android debugger blocks, and you can manipulate things in Tcl. The first is listening for the device and the second is using get-state. Both block.

You can actually manage a “state machine” of two states inside a while(1) loop, because each process blocks. I couldn’t get this to work with a GUI, so I had to improvise:

| Why no, you are not looking at |
| a command-line screen.         |

The transition from listening for devices to state sniffing is plugging in the tablet. The transition back is when the tablet is disconnected.

Code generating code

I wrote a tool to spit batch script, a learning device for learning ASP flows. This is almost the last nail in the coffin; after this, what I know is far-known, and there is little left to commend me. The low-hanging fruit has been picked for a while, and we have several problem solvers now.

You can, if you like, wrap Excel macros, AutoIt-compiled executables, batch scripts and Tcl libraries into a standalone application. You can generate graphs and PivotTables, address DLLs and manage an arbitrary canvas. I mean, for me, Windows development reached a local high point with this. The only things left are threads and games.

What do I do now?

Learning hypothesis

Learning occurs from either of two routes: memorizing everything as I go, or beginning from a task and repeating a cycle of vacuum-discard-keep. I will be the first to say that among self-motivated individuals, I am the worst of them: a procrastinator, easily discouraged, prone to naps, and often distracted.

If I memorize it, I have to review it. If I figure out the task, it has to be repeatable. As a programmer, it sounds best to encode concepts into code: its execution is demonstration; its content is the concept. Where the algorithms are unknown or intractable, use a prompt and lean on human conclusions:

Is your input a declarative sentence [y/n]?

Problems and exercises are something else entirely. That is where a rubric comes in. The criteria can vary. I would only record representative problems, exceptional exercises, and demonstrative examples. These are my miniature case studies. These I would consult, in hopeful trust, a lighter reference than the text.

Proxy mirror

I use the word “proxy” when it makes sense, but imagining from the outside-in is always confusing. Setting a form to forward requests to another server, crunching through the data, cleaning up the tag debris, and presenting a fresh face to the user – sure, I know that. But “setting up a proxied connection,” or “it goes through a proxy,” continues to boggle at the surface.

For example, squid is a “caching proxy.” So I have to imagine I am developing squid; how do I be a caching proxy? A user visits my page and is presented with a list of links. The anchor tags could all point to a single CGI mapping script, like /goto.cgi?link=1, /goto.cgi?link=2, etc. All the user sees are the remote URLs.

When the user clicks a link, I take the request and present a page without the (longer) trip. Assuming it’s longer, even. Or not longer, but streamlined. Or stripped of Javascript. The server (program) acts as a “proxy” by how it treats the HTTP request.

Mapping models

There’s actually two (at least) conceptual models in networking: the OSI model and the TCP/IP model. I had assumed they were the same – vaguely – but they are related in the best way that layered ideas could be: TCP/IP can be mapped onto OSI if you consider OSI as a generic model of a “communications stack.”

If you hear the phrase “Ethernet is layer 1 and 2 of the OSI model” or “TCP is the layer 4 protocol of the OSI model,” that means the TCP/IP concepts are fitted in the OSI stack from Physical (layer 1), Data Link (layer 2) to Transport (layer 4), and beyond.

Regarding network tools, it seems there’s a lot of emphasis on packets: filtering packets, inspecting packets, crafting packets. Less so, seemingly, on the wrapped portions of the data, into frames and segments, and the transmission of bits.

Perhaps because the “transport” layer in both models are the boundary between the application space and the data flow, where the best vectors can be found.