/Library/Application\ Support/VMware\ Fusion/boot.sh --start|stop

I think I missed somewhere how to populate and bring online a VMWare image without pointy-clicky actions. No worries.

I do notice that when my MacOSX-10.6.2 — a fairly modern OS — changes networking setup (VPN connects, disconnect Wifi, renew DHCP, etc) there is a huge shuffle of activity and some log messages about the Mac doing “the right thing”: backups, sync, etc. Most of that seems lightweight, but if I don’t really need it, I like to deactivate it.

The VMWare stuff is not so necessary today, so I decided to offline it.

I found its config as a launchd system-wide Daemon: /Library/LaunchDaemons/com.vmware.launchd.vmware.plist — so taking that apart, I found it’s a one-shot fire-and-forget like the cheesy rcX.d that I don’t like about linux (as discussed, based on a hotly-contested decision to make daemon start/stop possible in packages added/removed from the system — USL did this, whereas ODT collects a /etc/inittab.d/ directory, which allows auto-restart)

So I took that apart.

cauldron:~ allanc$ sudo /Library/Application\ Support/VMware\ Fusion/boot.sh --start
VMware Fusion 196839: Starting VMware Fusion:
chown: /Library/Application Support/VMware Fusion/isoimages/antivirus.iso: No such file or directory
Internet Software Consortium DHCP Server 2.0
Copyright 1995, 1996, 1997, 1998, 1999 The Internet Software Consortium.
All rights reserved.

Configured subnet: 172.16.83.0
Setting vmnet-dhcp IP address: 172.16.83.254
Opened:
Recving on VNet/vmnet1/172.16.83.0
Sending on VNet/vmnet1/172.16.83.0
Verifying and re-installing files from /Library/Application Support/VMware Fusion/thnuclnt


This has a few gems to consider: what’s that yummy antivirus.iso, and how can I use that to auto-define a VM? Hmmm…

Anyhow, for when I forget this next time, this how to start/stop the VMs.

It’s very difficult to maintain any sort of compatibility with another company, even when there is relatively tight communication.

It’s even difficult to maintain compatibility when there’s no sharing, communication, or agreement. It’s very much like hammering changes with set of tests, and looking for leakage.

It’s much more difficult when the two entities are competing providers.

When the compatibility issue is within the same company, within iterations of the same product, there’s no excuse.

What’s the Apple ideal here? carry 5 separate phones?

Am I flirting with the risk of losing my Apple ID?

I’m not some evil phone-cracker, and I pay for everything I have. Heck, I use bittorrent as a try-before-you-buy. I’ve purchased as many as 4 copies of software (hello, Starcraft) rather than cheat when I’m in the wrong country and need something.

Checking my system logs, Apple software itself has shaky behavior: warnings that it’s violated its own constraints, obsolete function-calls, etc. The cheap iPhone cable I picked up occasionally seems to disconnect (ie every time with the older phone, never with the newer)

Is it possible that my unlocked phone, plus one of Apple’s own errors, plus this cheesy cable, can brand me as a thief, cracker, all-around bad-guy?

Apple also make a product-suite called iWork, which competes with Microsoft Office. For example, Pages competes with Microsoft Word.

Suppose Apple offered these products on Microsoft Windows — a direct competitor to their OS product, and a product which directly competes with their product on their competing OS. Whether “Pages” works smoothly, or doesn’t, that probably reflects poorly on the “Pages” product, and by allusion, whether all of Apple software is generally of good or poor quality.

If “Pages” tends to run very very well on Apple OSX, but poorly on Microsoft Windows, it probably implies that Windows has performance problems, and OSX is obviously the better OS to run things like the “Pages” application. That means that making “Pages” run well or poorly on the competing OS reflects on the perceived quality of the competing OS.

In short, Apple could make Windows look bad, and influence buyers over to OSX.

Does that seem fair? Who is really to blame? Doesn’t Apple have the obligation to at least adapt to the environment to which it’s writing software, and make it work? Isn’t that target environment really the foundation to which Apple has to make their product work? At the end of the day, the OS came before the application, so errors should be resolved in the application side.

Application errors are the application’s fault, not the OS. To claim otherwise gives reason to question the objectiveness of the auditor.

Same issue, but Microsoft making Office run on Mac. It runs poorly, hogs resources, and generally runs for short times without crashing. Obviously, this is Microsoft’s issue to deal with; to think otherwise implies a certain bias away from Apple.

How logical is this:

$ sudo rpm -Uvh /home/repos/kludge/doxygen-1.6.0-1.i386.rpm
Preparing... ########################################### [100%]
package doxygen-1.4.7-1.1.i386 (which is newer than doxygen-1.6.0-1.i386) is already installed


Version 1.4.7 newer than version 1.6.0? It’s not logical. I’m assuming it’s because of Epoch, but Epoch data doesn’t show. Epoch is hidden, secret, and causes confusion like the confusion above.

…and really, once an epoch is set, it’s too easy just to bump it up, and that causes a complete scramble in the orderly, logical increase of version numbers.

The only way to cripple this is to choose the highest epoch number possible. That’s why my Epochs are maxint.

I just made it easier.

Since I live out of a suitcase, this makes my life easier.

I’m using the same process as before (using the evil “screen” tool), the GUC232A, plus a few extra bits, totalling:

• A Mac
• A USB-to-Serial device using the PL2303 (like my GUC232A made-in-China for $10, but a bit more expensive as RadioShack #55004488)
• A Basic DB9 Null Modem (ie RadioShack #26-264)
• A Basic DB9 Female/Female Gender-Changer (ie RadioShack #26-230)

Notice how these things are easy to get to? I think a WinTel works in place of the Mac, but mine don’t stay running for long enough.

Anyone from JDSU may say “well, gee, this is fairly basic”, but rather than follow the rules like a mantra, I wanted to do this with easier-to-pack parts that can be replaced or cross-shipped if needed.

This is what works:

The trick is that the GUC232A is only 45cm/18inches long, but I can put a standard USB extension on it, route it through a US-4A or bang it on an unused server port anywhere.

The numbers have a bit of a delicious pattern; let me expand a bit from the Wired How-to Article, which presented this example:

The Digits themselves break down as follows:

Simple, right? The barcode will also start and end in a 0-0110 sequence, which breaks the xx-xxx pattern. I cannot see Mr Washington’s article, the hosting has trashed it, so maybe this stuff is already discussed. The Wired Article is really hard to take apart from there — examples would have been nice — so I’ve expanded a bit on it.

Although we could look at the barcode digits as simple replacement cyphers — similar to the glyphs on the TV show “Fringe” — there is a key to the barcoding numbers themselves that would let a reader build a barcode cheat-sheet or lookup just before decoding a barcode to reduce the chances of error. Let’s remap the table above, add sample barcodes, move the zero after the 9, and add an asterisk markup so that we have an example of that as well:

digit	code	barcode
1	10-001
2	01-001
3	11-000
4	00-101
5	10-100
6	01-100
7	00-011
8	10-010
9	01-010
0	00-110
*	0-0110

You can see how the progression of the 4 leftmost digits of each 5-bit sequence is actually a binary increment. The rule for that sequence seems to be “no more than two ones per digit”, and the 5th digit toggles one/zero to ensure that each sequence has two. Zero is pushed up to the “ten” spot, so it doesn’t have to suffer the indignity of no ones at all — for which the check bit would have to be 2. And what about 7? skipped. above, 7 is actually 8, 8 is actually 9, etc.

Asterisk is basically “zero” but with the spacer moved, perhaps to help key the scanner to the size and use the data itself as start/stop bits, the same way the 6-of-8 is done on an old floppy disk (leading bits are zero, after a spin there’s enough 0-0-1 and 0-0-0-etc to key the reader).

So now we have the magical logic to generate the bit patterns for the barcode digits, let’s markup the barcode and overlay some digits:

Now that looks a lot easier to digest.

Comments?

He didn’t ask what I had done, I didn’t volunteer it. I don’t need to swing a pedigree around, usually the recommendation I make are fairly obvious, sometimes only in hindsight.

It seems he and others seem to believe that if they haven’t heard of a particular issue, it cannot occur. This ignores:

• Problems that occur that are not voiced because “it’s no use, they’ll never fix it”
• Problems raised that are not escalated to the entity that can make a difference
• Problems that are raised high enough, but are deemed “not a real problem because I haven’t seen it”
• Problems difficult to replicate in a different country (similar to the comma problem I had in shell-based math, fails only in France)

People who discuss design and are aware of staffing/labour management don’t often bring things up for no reason. Of course, there is always room for a “painting the bike shed” discussion, but no one intends to waste staff hours. Typically, resolving things at design-time avoid staff-hours down the road.

Young architects don’t fully understand this, until they’ve done a few projects, and realize that they cannot personally see every problem.

It’s the equivalent of when software developers realize they cannot personally fix every known problem.

“Seeing is Believing”, eventually we get past the “Not Seeing is disbelieving” stage.

I remember this same argument, but by proxy: “I know a really smart guy, and he didn’t fix that problem, so that problem can never occur obviously”. I’m sure the logic errors there are obvious.

In this case, I elected to make my changes, and discuss them in hindsight. Some people recognize that I have the chinese habit of smiling and stopping when I see that I’m in an impossible task such as describing a round world to early Europeans. I don’t want to avoid making these changes, because that results in a waste of staff-hours that I don’t want to cause just to prove my point.

I’m not much a fan of waiting for my Wintel box to boot up or wake up, and it needs so many additional things to work: an extra trackball because the touchpad sucks, needs a wart on the bottom for a serial connector, needs much bigger power connector with extra internationalization tools to connect to foreign power sockets, etc. I fear when I’m on a client’s site, and the serial port in the wart doesn’t work… like a week and a half ago: I had to borrow a laptop to connect to the devices, which wasn’t very professional. I decided I’d find an alternative, and my Mac just always works.

I wanted a way to connect to one using my Mac OSX-10.6.1. The following works:

1. install osx-pl2303 with this link: http://sourceforge.net/projects/osx-pl2303/files/osx-pl2303/0.3.1/osx-pl2303-0.3.1-10.4-universal.dmg/download
2. OK, I rebooted rather than load the driver from the command-line.
3. You can plug in your device and check for the driver using kextstat — mine shows nl.bjaelectronics.driver.PL2303 (1.0.0d1)
4. connect using the cable that works on your Wintel to the PL2303 device (mine’s a GUC232A made in China)
5. Mac OSX comes with the screen tool, so I used screen /dev/cu.PL2303-00002006 57600
6. works fine

This process might work just as well on a Wintel, and is a smaller device to carry.

BTW: The patch is right here: nagios-autoheader.patch

Autoheader is a tool that creates the header file associated with autoconf-generated configure; autotools (ie autoreconf) tend to assume that if you’re using AC_CONFIG_HEADERS(), you have a header file generated from your configure.in or configure.ac.

FWIW, Nagios’ use of AC_CONFIG_HEADER(file1 file2 file3) is actually converted to AC_CONFIG_HEADERS(file1), but not using the plural makes it confuse autoheader a bit.

Consider that maintaining twenty files is more difficult than maintaining one; maintaining two files is only slightly more difficult, but still is an entry-point for human error.

Just like driving on the left (former British colonies, for example) is more difficult after driving on the right (everywhere else); for the same reason, doing things in a way that differs from the mainstream is more difficult for others — who are used to the mainstream — to adapt to. The corollary to this: approaching the mainstream way allows more developers to maintain your work.

The other benefit of joining the mainstream is that you gain from how the mainstream has “moved on”, and developed added benefits and utilities. For example, automake reduces the maintenance of makefiles, and gives you “make dist”. Nagios has a bunch of unusual scripts ot maintain versions of things, but Autotools do that by defining in the configure.in and substituting at ./configure time. This ties into the “maintaining fewer files” above as well as doing things in the conventional manner.

Note that it makes no difference whether a project has done it a certain way since USL times — a new user sees it for the first time only when they first see it, with no regard for how long it’s been like that. This is to say that if it looks broken when the user first starts to work with it, it doesn’t matter how long it’s been broken, or if that method wasn’t considered “broken” when filing a stack of cards for batch-processing.

The small change I’ve done today allows Nagios to approach the current conventional method, and opens the path for further enhancements in a step-by-step progression of little changes at a time.

(Installing RDC-2.0.3)

Part-and-parcel to this, if I ask for a piece of software, chances are, I want that piece of software. No more, no less.

Installing Remote Display Connection v2.0.3, I suddenly had to quit other Microsoft software because it was forcing an update. You’ll notice above that this is installing Remote Display Connection, it has nothing to do with Entourage.

(Surprise! Hidden update)

… but Aha! You can’t update something secretly if it’s running!

I don’t recall asking for an update. Chances are, I had that software open because I was using it. If I wasn’t, it would not be open. Let’s not force me to stop working just to get more attention, shall we Microsoft? And lets not run updaters or anything else secretly that I didn’t ask for.

I only wanted a Remote Display Connection — nothing more — and only because I’m forced to connect to a Windows server. …because your networking protocol is so bloody weak, I have to use FTP.

Some of the changes will probably filter down into 10.5.x, but not all — only enough to reduce their engineering costs of back-ported support issues.

One interesting one is the Printer Drivers Update.

The gist: Software Update will also update drivers for third-party printer.

OK, not earth-shattering revolutionary stuff, but what I see is:
Apple Software Update will begin to update third-party content on your behalf

That’s like updating the extra little free tools I have, such as Adium, sfCubed, MailDrop, Perian, Cha-ching, Visual Hub (if it wasn’t toast), VLC. It’s a step towards that goal, which is really: making it simpler to update.

Google aggregates RSS feed in Google Reader; RSS can easily represent updates with a rich XML digital description; these could be “subscribed to” in Software Update. We therefore have user-selected update channels, just like OpenSource and Linux have (for free).

If you want to play further, here it is:

• vixynet-0.1-1.i386.rpm (85k de106d64e11cd5171620487f2dc1283a)
• vixynet-0.1-1.src.rpm (150k d28d596ebb3d7114234915aa18e23ef3)

• Affects bug #1712160
• Includes submitted patch #1814075

You can grab the patch using rpm2cpio vixynet-0.1-1.src.rpm|cpio -idumB

The RPM Specfile is still a bit trashed, and you can see I nullified the epoch (never should have been invented)

Installed, configured, and POPping mail from gmail already.

Gmail accepts only a few ports for POP (109, 110, 143, 220, 993, 995, 1110, 2221) so I changed my config from the default port 2000 to 2221:
/etc/sysconfig/freepops

#BIND_IP=127.0.0.1
BIND_PORT=2221
LP_OPTIONS="-v -d -l /var/log/freepopsd"


Assuming my own server with freepops installed is y.example.com, and my username on yahoo is chickenandporn@yahoo.com, my config in Gmail looks like:

gmail POP config with FreePOPs

• http://r.chickenandporn.com/freepops-0.2.9-1.src.rpm (2.0M 53e475d6ce051b68111e845542eca23a)
• http://r.chickenandporn.com/freepops-0.2.9-1.i386.rpm (1.5M 6f9482fde5bdae2a299a876c914655bc)

Changes: version bumps:

• bump wordpress-mu to 2.8.4a
• bump wp-bar wp-bar from 0.5.7 to 0.5.8
• fixed Magpie-RSS due to “namespace” suddenly being a reserved word in PHP (resulting in a blank page displayed)

Changes: added items: (none)

• added google analytics
• added a favicon.ico default for the themes that don’t provide (reduces errorlog spam)

The build is available here:

• wordpress-mu-2.8.4a-9.noarch.rpm (7.1M adc9e3a01dd3a5c1595fc9de34aecfb5)
• wordpress-mu-2.8.4a-9.src.rpm (8.0M b30472658e7c5ede4b7c479992480bd3)

Luckily, autoreconf works now. Considerably better, more portable, and I don’t have to maintain it.

40+ requests daily still come in for my autogen.sh script — even though my site lost a disk and was offline for a month. It wasn’t so complex.

For a new project, or a bare SVN or CVS checkout (or the GIT equiv):

autoreconf -vfi or autoreconf --install

Seriously. Try it. When the autotools get updated, autoreconf does as well, so you don’t have to. Plus, if your version is new than another developer, you don’t have to make a portable autogen.sh; rather in the vein of qmake and Imake, the platform would already have the right versions to work with the platform rather than the sourcebase figuring it out.

In this case, I like the platform knowing what works best with the dev tools you already had to install on the platform (it’s a developer-side thing, not a get/build/user side)

So: don’t use autogen.sh. I’ve revoked my butt-kicking-great version for this reason.

A bit of a tangent, I had an order from Dell for 600 servers — it was a replication gig, so they all had to be the same. the first 350 or so were, but Dell changed suppliers for some of the components mid-stream, so we had 9.1GB drives mixed with 9.095GB drives from a different manufacturer, and a swapped out video driver. Where we needed “exact”, we got “same difference, right?”, and the replication had to be tailored for four platforms rather than one. Replication’s great for exactly identical supportable servers, but sometimes lacks flexibility.

How does that affect our Genesis? It means that the system is installed from pre-built, known-tested (binaries, testing the toolchain as well), pre-staged (faster download) content. It’s entirely repeatable, and easy to maintain and support if you’re willing to work on it longer than the 47 minutes it takes to replace the server (by LAN; faster using DVD).

Emerge is a tool used by Gentoo installers to interact with the Portage system to download, build, and install sourcecode for a new install. It downloads sourcecode, builds with whatever toolchain it has, and installs. It runs with elevated privilege, which is normal if we weren’t downloading foreign content. Installing 600 means 600 downloads of a few thousand software projects, but can adapt to mid-stream changes in HW. mid-stream changes in software versions means that you don’t get what the other guy got.

By contrast, RPM systems let you install the exact same binaries as the guy beside you, you can cache the pre-built binary payload, the dependency-table is known before the install begins, you can marshal requirements and make the change is a relatively short time.

It would be silly to install a second system of dependency-mapping that competes with the OS. Seriously, when you go to London, you drive on the left; when you’re on RedHat, track your dependencies in RPM — if your wheel is better, don’t reinvent, augment the one that’s there. Share your improvement. That’s the Stallman way, and the GPL, isn’t it?

“RPM” is like the prefabricated construction of the world.

“make World” was how X11 was built — Imake && make World. Imake was similar to qmake in that it needed the platform defined first in the tool before the portable Imakefiles could be converted to makefiles to run the build. Opensource turned to automake, autconf, libtool for unknown platforms for the chance to “figure out” the unknown platform before build starts, but the Embedded space and cross-compiling seems to favour Qt (qmake) for some embedded devices, BuildTool and OpenEmbedded for others.

“make World” took a long time.

SSO installs on system 5 rel 5 were like “custom” installs on system 3.2 rel 4.2 except that there was a huge design around concentric containers: Packages, Parcels, Containers, and Products. It added logical aggregates of packages as well as namespaces to the packaging world. It’s gone, we sued them in a situation similar to a GPL violation. Unfortunately, the technologies and innovation are lost, since we don’t read the court cases nor the ~23 years of development before that.

Ian Murdock gave his Linux variant a detailed specification for package quality. Debian Linux also gave us “apt”, which lets us one-command-install a server from binary packages, or get the dependencies of a source build to develop/extend a specific package. Reducing user-input reduces chances for human error.

Debian is like adding strict contracts for quality-appraisal to Prefabrication.

CPAN is a resource that can be harvested for yesterday’s latest perl: go to the ‘net, download the latest, build and install, running last night’s updated build scripts with permissions to trash a system or install malicious software. No problem, just update the source package tomorrow. No one will check… for datacenters, trusted systems, a known bill-of-materials (BOM) is needed before agreeing to do the work. I haven’t seen many datacenter change-requests go through with “I don’t know what it changes” and “I don’t know how much software it needs or how long it takes” as entries. CPAN is great for people who can rebuild a server if necessary.

CPAN is like when you need the latest tools, building methods, plumbers, framers, roofers, foundation work, landscapers, and you’ll just ship them raw materials and have it assembled onsite. It takes longer, and sometimes, conflicts break out at the soup-truck, but eventually, you’ll get the latest fusion of last week’s Tokyo and Paris fashion.

Dependencies change; installing 175 packages that change often gives a high probability of resulting in a new combination of all the versions of things. Tracking versions as part of dependencies is logistically easier with the Package/Component/Parcel system of SSOs and reduces the chance of collision (how many “httpd” are there? Cern::httpd and Apache::httpd differ). A BOM is something your system can check against currently-installed packages, and the user can also check. Binaries are already built, and others have used them before you get them, so there’s less risk of breakage if thousands have already installed it since it was released a week before.

Binaries built by others have less variance, therefore are not the most efficient for your precise hardware, risking 2-3% efficiency for a smaller set of combinations.

This is why I prefer RPM, CPM, SSO, DEB, even “custom” — a confirmable predictable BOM of pre-built components — over build-in-place systems. There a higher degree of deliberate behavior, a lower chance through an innocent patch-bump to break a critical system through indirectly escalating degree of change. Build-in-place takes a long time, and done twice will get different results, but usually builds a functional system and allows a basement hack to go forward if you have the time to wait for your environment to be built.

I’m sure you’ve heard these same arguments before.

Update 2009-08-20 21:09Z: My patch for Doxygen was accepted

This is an SVN build, so may differ slightly from the canonical v1.6.0 release.

Changes:

• Correction to specfile and root-level Makefile to match pathnames

The build is available here:

• doxygen-1.6.0-1.i386.rpm (3.1M 675ec48a8423afa46da25b81304fc29b)
• doxygen-1.6.0-1.src.rpm (3.0M 800cb50b846c6d631cbb31c734564d36)

My patch looks like this

• doxygen-1.6.0-svn-build.patch (1.3k 660b0f72c4168dc2b757d82e53a91ae8)

examples/simple_prog_desc

Changes:

• back out the required autoconf from 2.63 to 2.59 (created $(docdir) problems)
• version info is in configure.ac only (specfile imports)
• specfile in root directory, allowing smooth “rpmbuild -ta mscgen-0.17.tar.gz”
• add a AC_SEARCH_LIBS to ensure -lgd is in the link line

My deliverable is a bit unclean in that I didn’t bump the release from #1, and left a tainted build source rather than pristine+patch. My bad.

The build is available here:

• mscgen-0.17-1.i386.rpm (42k 8db2ed6e1811c996be4ddbee96b95b68)
• mscgen-0.17-1.src.rpm (164k 23c32e21611dd457552bff96274691c8)