While doing the dishes tonight, I was thinking about a simulation VM that mimics the low-level semantics of the real world. Data-types would match substance, the basic constructs of all matter. Functional abstractions would model the interactions between pieces of matter. And threads of execution would simulate the application of energy to the system.

Matter is essentially data that changes frequently, based on interactions and unseen forces. Most interactions can be modeled as data with an algorithmic aspect — the data as part of a matter-map and the interaction as functionality. Threads of energy would iterate related interactions, which in turn would aply the datum of the matter with the algorithms of the interactions.

I’m sure that this isn’t an entirely accurate picture of the universe, but it is an interesting approach to modeling it. The part that really struck me was that it could be implemented as a high-level virtual-machine. The instruction set of the machine would know how to combine the operands, with the result as new matter and energy. Execution as energy; functional definition as combinatory and interaction code; and data as matter. Seems simple.

Here’s an example, in pseudo-matter-perl:

($matter, $energy) = combine(2 * $H2, $O);
$e = &$energy($matter);
print "$e, $matter, $energyn";

Running the simulation would yield:

$ ./make_water
572 kJ, 2 * (H2O), 0x4358FFE8

The Perl-ish example above shows that a VM wouldn’t really be needed, if a suitable abstraction could be designed. I was too lazy to come up with an assembly syntax for the universe, a hint that an abstraction might be a simpler path. A concrete simulation-VM, though, would allow the operations to be highly optimised, and would allow the basic language to mirror the domain more precisely.

Thinking about a universe simulator was a good way to escape the reality of doing the dishes. It reminded me that VMs are a domain-abstraction tool, with advantages and disatvantages over language-constrained abstractions. I would probably favour the VM-approach, mostly because of the fine-grain of control it yields over the language and data layouts, and the distance it gives you from the limitations of existing languages. But the advantage comes at the cost of complexity, which is at odds with my lazy nature.

I’ve run a weblog for several years now. It has been a different blog every few years, changing as I mature my way through life. My current site, warpedvisions has been fun, but I’m not sure it’s worth the effort.

It’s not the blogging that I’m thinking of getting out of, rather it’s the hosting and site maintenance that seems to be a bit of a time-sink. Not to mention the cost of hosting, domains, and all of the other related bits. The cost isn’t out-of-band where the budget is concerned, but it just doesn’t make sense as I don’t enjoy that part of the blogging. It’s funny too, I fled the automated tools a couple of years back in search of more control over the site. Full circle, I guess.

So why pay for the luxury of managing the nuts and bolts of a web site? I’m really hoping that TypePad is reasonably priced … as it would allow me to write without the burden of keeping it all going. Even if it’s not within my frugal range, I could survive on one of the other less-involved services. It’s about the writing anyway.

And that’s the interesting thing I’ve discovered in my years of blogging. It is the writing I love. I mean I really love to write; the process of smearing my cranium across the page is great. Not that many people have ever read my stuff with any regularity, that’s not the point anyway. I’m not yet sure what it is about writing that I’m digging, but that doesn’t matter yet as it’s just cool to find stuff I love to do.

I spent most of the week rebuilding a test rig to simulate a customer network problem. It has a strange topology, so scaling it to a reasonable testing size was a challenge. The resulting mountain of embedded PCs, simulation PCs, and networking equipment dissipates a few hundred watts of heat, and in one of the hottest weeks of the year. Then there’s the noise, from dozens of tiny fans doing their best to save the many CPUs from meltdown. Hardware scales so poorly.

I think this is the reason I ended up loving software so much — the total disconnect from the complexities and limitations of the real world. Not that software is simple, but inter-connecting 10,000 items is only marginally more complex than inter-connecting 10 items. Now imagine connecting 10,000 network devices? Hardware complexity scales at some inverse proportion to software complexity.

The setup I’ve been working on simulates a handful of discrete networks, each with a few levels of hubs, switches, and routers. I have no idea why hubs play into this mix, but they do. It’s been a long time since I’ve seen a hub too, since switch prices have been so reasonable in recent years. And factoring the limitations of hubs into the bandwidth capacity is quite a job too, as it has been a while since I thought about how bandwidth-impaired hubs really are. The difference in bandwidth can be incredible, a few orders of magnitude more than would seem obvious. That depends on where the hub is, of course.

My voyage into network simulation reminded me how broad the field of networking is. I ran into several technical aspects of networking that I had never considered before, and I’ve set up several networks in the past. Not that I’m a network guy, but I know a few things. Luckily we have a good admin in our other office, so my dumb questions were answered quickly. Experts are important to an organization, as is knowing who they are.

It was also entertaining to go back in time to Windows NT4 and 98. My potpourri of simulation PCs include a few 98-laden laptops, and some NT4-ridden ‘embedded’ units. All of the actual test hardware is 2k or better, but the simulation stuff is old. Another testament to my very short memory: network configuration has really improved in newer versions of Windows. Microsoft really does improve things. This all would have been easier to set up, of course, with BSD or some Linux variant. But that’s probably because I prefer that approach to network configuration, not because it is simpler. Nothing is hidden, it is all there in plain site, in plain-old-text, and in well documented form. I really do hate it when things are obscured.

The network setup ended up taking much longer than it should of. We have piles of hardware and cables organized in our store rooms, and connected to the many test rigs around the office. But a recent 100mph project derailed most of our meticulous organization, and mixed up the piles of RJ45 ethernet cabling with the piles of RJ45 serial-line cabling (not to mention the various types of cross-overs). I know you’re not supposed to use RJ45 for serial-cabling, but it ends up everyone in this industry does — and there is no standard pinnout amongst the vendors we buy RJ45-serial equipment from. So, much of my week was spent finding cables that were actually useful for ethernet networks. A small example of why standards are good, and how sometimes the users of something are more aware of what is useful than the standards bodies are. RJ45/CAT5 make for damned convinient serial cables. They look a lot like ethernet cables too.

This sort of hardware setup isn’t actually complicated, but it is certainly tedious and time-consuming. Each step of a setup needs to be executed and validated, at the granularity of individual PCs and wire-connections. Oh, and not to mention the skill of creative-will required to snake dozens of cables in a confined space. Add to it all the OS and software setup, and a week disappears into the ether.