I'm setting up a new server with Solaris 11 Express. I had to change out the hardware (long story; post later), so I decided to update the OS. The old one was running Solaris 10 update 3 (which I think was 11/06). Yeah, old.

There are lots of things I like about Solaris 11. One of the things that I don't like is that they removed a whole bunch of FOSS software that used to be in OpenSolaris. What's worse, they removed a bunch that had been in Solaris 10! WTF, guys?

Anyway, I like to use squirrelmail every now and then, and squirrelmail really likes to have a spelling checker. Well, I like for it to have a spelling checker. No problem -- aspell shipped with Solaris 10. I'll just install it and...

HEY!

Now, building aspell is not a big deal in any way. It's easy, and the spec file is pretty simple too. (I use pkgbuild because it's a lot nicer than writing IPS manifests by hand.)

The problem is that all of the dictionaries are separate, and there are more than 80 of them. Yeah, I could get by with just a few, but I'm a completionist. I also have delusions that other people may want to use them. With IPS, this is one of the things that's relatively easy.

The prospect of writing 80+ spec files is not appealing, even if the changes from file to file are small and simple. Downloading the files, munging the names, making the version numbers palatable to IPS (another post needed on that one!), and dealing with the other small details would be BORING. Tedious, too. I thought that's what these computer things were for...

So I spent probably more time than I would've just doing everything manually writing a program to do everything for me. And I mean everything. It'll download the list of dictionaries, go through it, download the files, write the spec files, build them, and clean up.

It's already been a good thing for me. I downloaded all the files by hand last week (BORING and TEDIOUS), and I hadn't noticed that the English dictionary had been updated since then. My script did. W00t!

I like it, and you can get it here. If you need a spec file for aspell, you can have that too.

If you just want the packages, you could install them from my IPS repo... If it were externally visible. Maybe by next week. I'll let you know.

I've written several times before about how the VM system in MacOS X sucks. But other than trying to fix my own problem, which was keeping the system usable while moving large amounts of data disk-to-disk, I never delved any deeper into the problem.

Well, Alec Muffett did. And what he found was very interesting. I reinstalled my work laptop last weekend, and following the recipe found at superuser.com, moved my swap files to a dedicated partition.

I also used pmset to move the location of my hibernation file. The documentation will tell you that it can't be moved to a non-root volume, and that's true. But when you think "volume" (in a MacOS X context, anyway) you probably think of a filesystem. In this case they're talking about a physical volume. So a partition on your boot disk is a-okay.

I'm not going to tell you that this changed my life and gave it new direction. But it is pretty novel (for me) to not have to wait several minutes for Firefox or VMWare Fusion to shut down. Novel and nice.

For the record, I think the vast majority of the benefit comes from tuning the high- and low-water marks on dynamic_pager. I don't think much of it has to do with it being on its own partition. But it doesn't hurt.

Firefox is becoming annoyingly slow, so it's time to dump some links and close some windows.

A while ago I was looking for some info on messages I saw in a friend's messages log. It was something like "leaked space: vdev 0, offset 0x40000, size 131072". I was worried that some space was being leaked.

Well, Google led me to one of Ben Rockwell's blog, where I found out about zdb, the ZFS debugger. Well, that was surprising. Also not documented well... not surprising.

From there I found Marco Leal's blog, where he has an excellent series on ZFS internals:

• Part 1


• Part 2


• Part 3


• Part 4


• Part 5


• Part 6


• Part 7


• Part 8


• Part 9

And then in even more roundabout fashion, there's Ben Rockwell's ARC stats script.

I found this site indirectly via ANN (it's listed as a source for the number of episodes of "君に届け", if you must know). It looks to be very comprehensive if you're interested in anime. It also lists TV shows, but evidently not reality / panel / sketch shows (which make up the bulk of Japanese TV, AFAICT).

http://cal.syoboi.jp/

All in Japanese, of course. I didn't trying running it through Google Translate, though that might be entertaining.

How to use a Japanese toilet:

http://www.asahi-net.or.jp/~ad8y-hys/movie.htm

Via Mutantfrog Travelogue I found this interesting interview with an ex-executive for a visual kei label.

It's over at Tokyo Damage Report, which looks to be pretty interesting in its own right.

And then there's a little follow-up.

Overall, very interesting but LONG. You have been warned, but read them anyway.

In today's BK1 comics update:

人妻爆乳アナウンサー由里子さん

"Married huge breasted TV announcer Yuriko-san"

I wonder what that's about?

This year looks like it'll be a pretty heavy travel year, just like last year. Personal travel will be way down, but I still expect to be spending a lot of time in airports this year.

I've been thinking that I'd like to have a list of all the airports that I've traveled through for the year. Mostly this is because I'll be in an airport thinking "This looks familiar, but when was I here?" or "I know I've been through this airport, but nothing looks familiar." A case in point is the Colorado Springs airport -- it didn't click for me until I was out in their bizarre rental car lot. (As an aside, it reminds me a lot of Reno, but without the slot machines.)

So I thought I'd put this little placeholder article here. I'll update it as the year progresses, and it'll expire once the new year comes.

I'm going to count each transit separately. For example, if I'm transferring through a hub, that counts as 1, since I never leave it. An end point will count as 2, once for when I arrive and once for when I depart. This would be complicated by one-day in-airport meetings, but that's not how I roll.

Totals:
DIA (Denver International): 5
AUS (Austin Bergstrom): 4
COS (Colorado Springs): 2
PDX (Portland International): 6
OAK (Oakland): 1
SJC (San Jose): 1

January:
DIA: 3
AUS: 2
COS: 2
PDX: 2

March:
PDX: 2
OAK (Oakland): 1
SJC (San Jose): 1

April:
PDX: 2
DIA: 2
AUS: 2

June:
PDX: 3
BOS (Boston Logan): 2
YVR (Vancouver, BC): 1
YYZ (Toronto, ON): 1
YQB (Quebec, QB): 1

July:
PDX: 1
YVR: 1
YYZ: 1
YQB: 1

August: NONE!

September: NONE! (The meeting was moved to coincide with vacation I'd planned to avoid said meeting.)

October:
PDX: 2
LAX (Los Angeles International): 1
IAD (Washington Dulles): 1
DCA (Washington Reagan): 1
DIA: 1

November: NONE!

December (planned):
PDX: 3
LAS (Las Vegas): 2
LAX: 1
NRT: 1 (vacation! woo hoo!)

If you're building stuff that links to libxml2 on Windows, and you get linker warnings like

warning LNK4217: locally defined symbol _xmlFree imported in function _eat_my_shorts

all that means is that you're probably linking with libxml2_a.lib and you didn't build your program with LIBXML_STATIC defined. So when you include the header files, all of the libxml2 functions get marked as "__declspec(dllimport) extern" instead of just "extern".

There you go, search engines. Hope this helps.

You can go back to sleep, since you probably don't care about installing any kind of Solaris on any kind of system that doesn't have a monitor. But if you do...

If you've been following OpenSolaris at all, you know they've totally re-thought the packaging system. Anything, after all, would on balance be better than the SysVr4 package crapola that Solaris has had since forever. (#1: No, I do not consider SunOS 4.x to be "Solaris 1"; #2: Maybe there is one thing that would be worse, and that's the "no package system", akin to what MacOS X has.) But none of the existing systems (RPM, Debian, installp, etc) were good enough, so we get a whole new one.

They've got some interesting ideas. One is that every package you'll ever need to install will be in a network-based repository. Want a package in a file? Sorry. Don't have network access to a repository? Sorry. I'm sure there's a way to get around this; the CD installer does it for sure. There's very little documentation, though and I haven't read through the source code. (We love Python, now, BTW... pass it along.) Overall, it's not too bad, except for the package server requirement. Guess what else you can't (officially) do? That's right... copy a package from one repo to another. I'm sure it's possible, but AFAIK there isn't a tool that enables it. I'm going to write one, I think.

They also decided to "re-think" JumpStart (which is the Solaris way of doing remote installs). This is less sensical to me, since JumpStart was already pretty good. But never mind that, it's new and shiny and "better". (Sorry... I forgot to save all the mailing list references. They're probably around if you search for them.)

My main problem with both new things is that they are both "no scripting allowed" zones. The reasoning goes something like "All post-install scripting (whether for packages or systems) exists to hack around deficiencies in those systems. Therefore if we correct the deficiencies in those systems, there will be no need for these hackish scripts. Thus we resolve to correct all the deficiencies and will allow no scripting."

This is a fine aspiration, but is not actually achievable, since it's impossible to foresee unforeseeable deficiencies. This has come up on several of the OpenSolaris mailing lists, and usually goes something like this:

Cust: I need scripting for installs.
Sol: Why do you need it? Be specific.
Cust: I need to do the following things:

Then (talking about system installs):
Sol: Do you really NEED to do those things, or just want them? If we let you script, it will destroy the purity of our system. Why don't you make a package that installs a service that will run the script on first boot?
Cust: Well, for one thing that'll require an extra reboot, and this fully loaded M9000-64 takes two hours to do that. So I'd like to avoid that if possible. Also, how are we supposed to work around bugs in Solaris that keep the first boot from even happening?
Sol: ...

OR (talking about package installs)
Sol: Point #3 is a bug in the software you're trying to install. You should fix it.
Cust: Uh, the software is all of GNOME. What about the other points?
Sol: Your package could install a service that runs the script.
Cust: There are going to be lots of services then, if each package needs to make a service to run its post-install scripts.
Sol: Most packages won't need post-install scripts, since the packaging system will be perfect. Look, it even has an action to create users!
Cust: ...

There are several problems that I can see:
1. The Solaris developers have a HUGE bias toward laptop/workstation. Witness the fact that the only way to do an install that does not require a monitor attached to the system is to do a remote install. That's also the only way to install a SPARC system, period.
2. The AI developers have read the JumpStart manuals and understand how it works, but do not understand how it's actually used for large installations. A small example: To set the hostname on an installed system with AI, you have to have a specific system configuration manifest registered in the install service for the installation you're going to do. Two hundred systems to install? Two hundred manifests that differ only in the smallest detail. Contrast this with JumpStart where you _could_ run add_install_client 200 times, but you probably won't because there are MUCH easier ways to accomplish that particular goal. And the hostname can be set based on what comes out of the naming service for the IP address you've given it. (If you want.)
3. Computer Science syndrome. I, too, once suffered from this. It's the preference to strive for the unattainable perfectly beautiful system rather than make one that's slightly less beautiful but works. This often manifests as "Not Invented Here" disease.

Personally, I think this stuff will be pretty good about 3 years after it makes its way into real Solaris. (Yes, OpenSolaris is "real", but big shops (from whence the big bucks come) don't use it.) My reasoning is:
- 2 years to REALLY convince the Solaris developers that their beautiful but inadequate system is hindering adoption by large customers
- 1 year to fix the problems (i.e. uglify the systems slightly)

I got lucky... I have 277 systems to install. I thought 264 of them would be running OpenSolaris, but it turns out only 64 will. So I'll just SSH to each one to run the finish script that I wrote to complete the installation. Yes, it's there to work around deficiencies in the installation process.

If there are any Solaris devs listening (there might be... those guys are like Kibo), here's a list of installer deficiencies I'm working around, though I doubt it'll make much difference:

1. Adding user SSH keys and setting up host keys -- saving them if they're new, replacing them if they've been previously archived. It's annoying when the host keys change every time you do an install.


2. Setting up NIS (domain, IP addresses of servers, etc)


3. Setting up netmasks


4. Converting to static IP (Network Automagic is nice for your laptop, but not for my server)


5. Fixing the GRUB menu (none of my systems have monitors). I know there's a fixed bug for this, but it didn't make 2009.06 and those are the only repo bits I can get.


6. Setting up resolv.conf (the DHCP server won't provide the ndots options, for example)


7. Setting up the name service switch to use files, NIS, and DNS (where appropriate)


8. Populating /etc/user_attr, so that the people who will actually admin the system can be root


9. Disabling graphical login (see #5 re: no monitor)


10. Setting the hostname based on the system IP address (I know I can do this within the current AI framework, but it's WAY too much work. Besides, I have to work around all these other problems anyway...)


Now I know (intellectually) that I could achieve #9 by using a site profile for SMF, but that's a one-liner in the script and I'm in a real hurry to get these systems installed and running. I'll learn all about SMF profiles some other time...