What's it all about, Alfie?

I've been working on my old simulation code a bit in the evenings and weekends now, just seeing if I could get the GaAs simulations to predict the oscillations of the 1D code. One of the things that hasn't bothered me - until now, is the timing methods used in the code. After all, I can time it on the wall clock and see how long it's taking, but I put in a decent level of effort all those many years ago to get the CPU split times for each phase of the simulation, and I thought it'd be nice to get them correct again.

I say 'again', because in the old f77 days, I'm sure dtime() was about as good as you could get. But in these new days of gfortran the values returned from dtime() are not in keeping with reality. I've looked at the GNU Fortran docs, and they say it's meant to return the elapsed seconds, but it's not. Maybe it's the build of gfortran I'm using, but I think it's more likely that dtime() is not what the new standard is using and I needed to move on.

So I did some digging in the code. Turns out F95 defined cpu_time() which returns the elapsed CPU seconds (as a real) for the execution of the app. This means that we need to put it into the code in a 'difference' mode - taking a reading at the top of the loop, and then at the bottom, and differencing the two for the incremental time that I was used to getting from dtime().

This wasn't all that hard, and in about an hour I had all the code re-fitted for the calls to cpu_time(). Thankfully, this is a much better timer and I get results that are making sense with the wall clock time I'm seeing for the runs. It's not like it's running any faster, or getting better answers, but it is at least more consistent, and I can look at the numbers and see what's more costly and from that see what I might need to do to alter the bias stepping, etc. Not amazing, but nice.

I've been trying to use Twitter (via Twitterrific) for the last week or so, and I have to say that I agree with the majority of the comments that I've read about Twitter: it's a nice idea, but the reliability is just so bad it's almost not something you can really depend on. The nicest thing about Twitter is that it's less real-time than IM, which is a downside if you try and use it as a replacement for IM, but it's a good thing if you try to use it for a different kind of communication.

For example, if I'm trying to communicate with a friend about a coding project, then IM is going to be as close to ideal as possible. It's like a phone call, but you can cut-n-paste code clips to one another and it gets the job done very nicely. But if the conversation is about scheduling something like a dinner or a movie, if the person isn't online at that instant, IM is no use. There's no really good delayed message system for IM. But that's what Twitter really is good about.

Then there's the 'broadcast' versus 'point-to-point' difference in the two. If you're in IM you have the ability to chat one-on-one to someone. Sure, you can fire up a chat client and go to some place and get a message room, etc. But that's not the same thing as using the IM client. It's intended for one-to-one messaging. Twitter is based on the broadcast idea, and in that, there are times when it is significantly better than the point-to-point of IM. Think about a group of friends. If one is going to a coffee shop, he can tweet that he'll be there in 10 mins, and if others want to join in, that's great. It's less formal because there's no guarantee that anyone will be listening at the time, but if they are, it's possible that many people might be listening.

It's clever and unique. I like the idea. I just wish they could keep it working more. I know it's not going to be supported by the likes of me - using Twitterrific, it's got to be ad-based and then maybe selling the tweets or the contact information about me to others. I don't mind... if I tweet it, it's in the public domain - you have to realize anyone could be listening. I just wish they'd do something to make it more reliable. Even if it meant subscriptions.

With all the fanfare of a little green duck, Adium 1.2.5 was released and I picked it up from the internal update system. I read a few of the release notes, looks like a lot of little bugs and maybe a few interactions with Spaces in Leopard, plus a few localizations. I've not had a problem with the sounds for a few releases, and just could not be happier with Adium. Incredible code. If you need an IM client on Mac OS X, get it.

One thing that would be nice is for Adium to remember the window you had open with the people (tabs) you were communicating with at the time. Then on restart, it'd just open up that same configuration. That would be nice to have. It's not a ton of time, but given that some of my conversations are with people that aren't online all day long, if they aren't online, then they don't show up in my buddy list and I can't easily pull them up. Minor issue, but a usability one that could be fixed if they maintained state across a restart.

I was chatting with a friend of mine on Twitter - through Twitterrific and he mentioned that he had gone into the NIB for Twitterrific and removed the tooltips for the mouse-overs of the name and the image. This makes the UI a lot cleaner as it already says who it is and it already says when it came in - so it's all redundant, and if you have the mouse over the window you're almost guaranteed to have a tooltip pop-up. So he cleared it out. I don't blame him, but I thought it'd be nicer to let the developers know what we wanted, and maybe they could fit in an option on the tooltips. Worth a try.

So I emailed them and got a reply back that was not surprising, but a touch disappointing. They are focused on the iPhone version, and when that's released in June they'll go back to the Mac version and they plan a significant upgrade to the UI.

So it's going to get addressed, but it's not going to be ready until the Fall. Which in itself is an interesting statement on the speed of their development - or at least the time they can devote to it. Then again, maybe they have significant changes in store and a little option would only take a few days (tops), but totally re-coding the app might take months. Hard to see, but it's possible.

In any case, if I want to strip out the tooltips, I'm going to have to fire up InterfaceBuilder and hack at it. Not sure that's what I want to do, but it's something to think about.

I have been playing with MacVim quite a bit recently, and reading a few things off the Google Groups mailing list (vim_mac) and noticed that some folks were saying that there was a noticeable update delay on MacVim on their boxes. They didn't give details on the machines they were using, but they did say that the faster update scheme that the other Vim for Mac OS X also uses is the ATSUI renderer - MMAtsuiRenderer (as it's called in MacVim). So I decided to give it a go, you never know, it could be amazingly fast.

So I got the preferences setting that isn't available in the GUI and set it up:

    defaults write org.vim.MacVim MMAtsuiRenderer -bool YES

and then restart MacVim. Turns out, it's faster, but it wasn't really slow on my MacBook Pro. Now, maybe the others are using slower MacBooks, or even G4 iBooks, I don't know. But it doesn't hurt to have the faster renderer being used.

I'm still amazed by the job they have done. Really exceptional.

UPDATE: it turns out that if you turn the ATSUI renderer ON (at least for version 7.1/26) then the mouse clicks don't move the cursor to the location clicked. This is not a "good thing" and I've posted a message on the vim_mac message board to see if I can get this either fixed in the next release, or if there's something else I need to set in order to get the click/moves working again. We'll have to wait and see, but for now, I'm turning it off as the updating wasn't bad at all, and I need to be able to click-n-move.

[4/25/08] UPDATE: I got news back from the vim_mac mailing list. It seems the mouse support for the ATSUI renderer is not in the code. It's a known issue that they are working on when they have the time. For now, I'll have to just use the NSTextView renderer which is OK with me.

I've been involved with computers since before the days of widespread Chat, ftp and telnet. It was initially modems with teletypes or (if you were lucky) a glass tty (terminal). There was nothing to download to - save the box you were logged into, and then it was pretty much your entire world. If you wanted to look at another system you hung up and dialed it. Period. It was all we had, and in relation to what came before (keycards and terminal rooms) it was heaven on earth. But things changed.

Ethernet changed a lot, we got networks of machines in college - not yet PCs, and the old hobby machines of the 70's didn't have ethernet cards in them. If you wanted to have them talk to one another you did a special serial cable with Tx/Rx crossed and then you were good to go. But by the time you had widespread adoption of ethernet, you had networks, and when you had networks it didn't take long to have telnet, ftp and chat.

I can remember first using ftp to get at things across the globe while in grad school. There were newsgroups that might publish the site and directory of something useful, and then with anonymous ftp, you could go get it. It wasn't fast, and there were no Google-like search engines in place... you had to log in, search the directory tree for the file you were looking for... download it and hope it made it down before you lost your connection. Still, this was big computer to big computer, it wasn't until the PCs came out that you really saw the growth of the Kermits, XModem, YModem, ZModem file transfer protocols. FTP was almost forgotten.

But IRC Chat staged a massive growth, and telnet was the way to get from one machine to another. So not everything was forgotten. But fast-forward to today. It's amazing to me to see that ftp, chat, and telnet (ssh) are as strong now as they were in the early days - not because something better hasn't come along, but because the work put into the documentation way back then.

Look at the RFC for FTP or Telnet someday... it's amazing the detail they went into. I've implemented both, and was immediately impressed that the RFC was right on point with the intended audience - people wanting to understand and implement the protocol. The docs are very well written, complete and detailed, but not overly verbose and wordy. These things were written by people wanting to pass on this knowledge to others in the industry and make sure that there were no lingering questions and problems.

FTP is, to this day, a great way to get files around, and is in every web browser around. Telnet (SSH) is virtually unchanged - save for the additional security, but is just as useful. It's Chat that seems to have taken on almost mythical proportions.

Look at all the Twittes, IMs, IRC Chat clients. It's all the same, basic premise - I type and you see it, you type and I see it. They first version I used was even called type on the Unix BSD4.x systems at Purdue. But look how many ways you can now communicate through this little concept. You've got the store-n-forward of SMS or Twitter... you've got the IRC Chat and a ton of different IMs. It's as if this - communication between people - was the real killer app of the network. Sharing a computer meant files and resources of one were available to another. Putting the machines on different desks took that away - only to be brought back by the network.

I use Chat (Colloquy), IM (Adium), and Twitter (Twitterrific) all day every day. It's fun to think about where things started and how they have evolved over the years. I'm sure the video chat will be bigger when the bandwidth is there, but right now, it's just not. Give it time, though, and it'll be just like all the Sci-Fi movies you've seen. It's a great time to be alive.

I've been a big fan of vi and Vim for a while. I started using it back in grad school and it's been on any Unix system (or Windows for that matter) that I've ever come across. Mac OS X has shipped with it in the 'console' mode since it came out, and yet they haven't spent the time to make it really a Cocoa app - and it's understandable. Priorities.

So when I came across the Vim for Mac OS X web site I was really jazzed. They had, essentially, gvim for Mac OS X. Nice. There were several things that kept me from using it full-time on the Mac and those were primarily limitations in gvim itself - to have multiple windows you had to have multiple gvim instances. But then today I was checking to see if the Vim for Mac OS X web site had an update from the 7.0.224 it's had for a while, and I went to the Vim wiki and it led me to MacVim.

Amazing. Nothing short of brilliant and stunning.

This guy, has put gVim to the level of a regular Mac OS X text editor. Multiple windows in the same running application instance... tabs to show multiple file buffers in the same window... transparency on the windows - it's amazing! It's a complete Mac app, but it's Vim!

I can leave it running without a window open, I can open multiple files in a window - open multiple windows, Cmd-W to close the window... it's everything that I had hoped for in Vim and it's working on Mac OS X now. It's even got code to check for updates! This is without a doubt the way to enjoy Vim on the Mac.

UPDATE: OK... I'm about as jazzed as I've been in a long time. This release of MacVim is amazing! For BBEdit, I built etags and get them into the Makefiles of a few projects. While it's not perfect because it'd be very difficult to be able to determine the context of the method invocation, for a lot of things, tags are really useful. It's nice to be able to jump around the code easily without having to move your hands from the keyboard. I guess that's the thing I like most about Vim - it's all Old School - just like me.

Yesterday Apple updated Safari to 3.1.1 fixing two bugs but not putting in the new WebKit that's passing the Acid3 test 100/100. Too bad. I was looking forward to that, but they may have a lot more work to do on that guy before it's ready for release. Still, it's nice that they keep on top of the problems folks have found and release updates as often as they do. Sometimes it's still amazing how big a memory footprint Safari can get to be on my laptop - easily passing the 200MB size with only two tabs open. The cache and 'history' of the working browser has got to be enormous. Anyway, it's great to have that updated.

The next update I got this morning was Transmit 3.6.5, and while I really like the work the Panic guys do, I'm still a little surprised that they don't have a more 'minimal' interface to Transmit. What they have is fine, if you're using an FTP client like a file browser, but most of the time for me it's more like a small extension to the system. Make it as seamless as possible - no need for big borders - more like Cyberduck. That's a minimalistic interface that I like for file transfer. Nothing that gets in the way or takes up pixels that it doesn't need. I like all the features, and I appreciate what they are doing, but I think it'd just be nice to be able to have an alternate GUI that was less into borders fluff, and more into "just the goods".

The last update this morning was Camino 1.6. While I'm not a big user of Camino, I can appreciate what they are doing, and at times it's nice to be able to fire up another browser and see if the web site I'm having problems with works any better with Camino than Safari. It's fast, clean, and a nice Mac app, so you gotta keep up to date and make sure they didn't throw in something really cool that could make it the best browser on the platform. This release is supposed to have a few nice GUI improvements and I'm sure they're nice. I just haven't had a lot of time to play with it. Maybe this weekend.

Like any self-respecting computer goober, I love getting the updates and seeing what others have done with their code. In each of these cases, it's more than just an app - these are things that the developers are seriously proud of, and they should be. This is some of the best software out there, written by passionate, dedicated folks. And it shows. Gotta love that.

I got an email this morning from the UnixEng crew - a good lot of guys and gals, to be sure, and they were saying that one of the machines we have here in the development group was having a ton of network errors. The switch was set to 100/Full, and typically, that's what we need because we've learned that the auto/auto negotiation seems to have more problems than it's worth.

So the network guy switched the port to auto/auto, and that helped a little, but I wanted to set the linux box to 100/Full because I know that's better than leaving it full auto. Typically, we do this when we build the box, but a lot of times it gets skipped (forgotten) because things start out working, only to fail at a later date.

Anyway, the nice tools to remember here are ethtool and ifconfig. If you run ifconfig and look at the data for the ethernet port (eth0 in this case), you can see if there's a likely problem in the port.

Typically, you might see:

   eth0   Link encap:Ethernet  HWaddr 00:17:A4:99:07:EF
          inet addr:146.180.7.94  Bcast:146.180.7.127  Mask:255.255.255.128
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:123456 errors:0 dropped:0 overruns:0 frame:0
          TX packets:123456 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelength:1000

but if you see large numbers for the errors or the collisions then you're probably looking at a duplex mismatch. The way to see what your card is set at right now is to run ethtool on the port:

   ethtool eth0

and a lot of nice, useful information about eth0 is going to spill out.

If the network card needs to be forced into a mode, then the easiest way to do this is to edit /etc/sysconfig/network-scripts/ifcfg-eth0 and add the line:

   ETHTOOL_OPTS="speed 100 duplex full autoneg off"

and a quick reboot later and things should be fine. That is they should be. Today it was something different.

When I made the changes to the /etc/sysconfig/network-scripts/ifcfg-eth0 file and rebooted, the services Avahi and HAL failed to start. When HAL failed to start, the box hung. Thankfully, I could get it to boot into single-user mode and start to look at things.

Google pointed to SELinux, but that was very clearly disabled on this box - as it should be. We looked at a lot of things - X11 drivers, etc. In the end, I was faced with the fact that it was the only thing that has changed on the box, and so I removed that one line.

Bingo! That was it. Now what's odd is that that line is on another box with the same hardware spec - so we're baffled as to why for this machine there's a problem. It could be the version of the kernel or packages - a yum update would help, but it's working now, so we may put that off. It's also possible that it's the switch ont he other end... but that's going to be very hard to pin down.

In the end, we're going to keep an eye on it, but what a mess trying to fix something like this.

I really love Sun hardware and software. My first exposure to Sun workstations was the 3/50 in grad school and it was the most impressive box I'd ever seen. Oh, I'd had an Amiga, and it was nice, but when I was at school and could work on a 3/50 - or later a 3/60, it was an entirely different experience. Night and day. Nothing beat Sun stuff. Nothing.

Then I went to Auburn, and again, Sun was king. Oh, we had PCs, and I had a nice Mac II, and later a IIci, but if you wanted to crunch numbers and display them nicely, Mac OS 6 or 7, or Windows 3.11 just didn't cut it. You had to get Sun.

Little did I know at the time that had I seen an SGI workstation, my opinion of Sun would have changed, and I would probably never have looked at Macs the same again. At heart, I'm a scientist and a numbers guy. Scientific apps and data visualization is what I love doing most.

Anyway... Sun ruled the roost. Then they stopped innovating. Solaris 2.5 was nice, 2.6 was good... heck, they all are nice, but they aren't anything in comparison to linux or Mac OS X these days. And here's the case that brought it to a head this week.

I've been working on writing a C++ wrapper for libcurl and I wrote it on the Mac where I knew I had a recent version of libcurl, with 32 and 64-bit support. Then I moved it to linux -in this case Fedora Core 7 on x86_64 and it again compiled without a hitch. Then I moved it to my Sun box to make sure it built there. I have to do this, and usually do it in this order as it's the fastest and easiest way I've found to get the cross-platform builds working.

When I went to Solaris I had to add an include for bzero() which on the Mac and Linux is in the more standard includes, but on Solaris 8 (9 and 10), it's in strings.h. No big deal, I added that. Then started the build again. It compiled the 32-bit version just fine and then hit the wall at the 64-bit version.

Oh, my code compiled just fine - it's generic C++ with a little STL, but it's the linking phase that messed up, and that's where Sun has been standing still.

Sun was one of the first to support 32-bit and 64-bit on the same deployment on the same hardware. It was an elegant solution - two sets of files. True, Apple had a trick up it's sleeve in it's historical use of the quad-FAT binary (HP-UX, Solaris, Intel, Motorola). This allowed them to jump ahead to a single file with multiple architectures and word-sizes. Linux copied Sun's ideas and delivered multiple libraries pretty early on, which brings everyone up to about the same level.

Almost.

The problem is that Sun has failed to recognize that libraries like libcurl, openssl, zlib, and the others that I've gotten from SunFreeware.com need to be available in the default installation of Solaris. I've got Solaris 8 and 10 and what's missing form them is significant. I know they have SunFreeware, but even there, they don't seem to have multiple architecture binaries of the packages. If they had, I'd be a happy camper. I have already gotten most of SunFreeware installed on my machines, but it's all the single 32-bit versions of the packages.

I can't be the only one that wants 64-bit versions of these libraries. Maybe Sun doesn't have to include them in the OS, but it'd be nice if I could get a CD of all the libraries on a linux box built into packages for installation. Disk space is cheap... install all of them both 32 and 64-bit. Then, should I want to make something in 64-bit mode, I can.

So I'm left looking at the Sun box and thinking how nice it could have been had Sun just kept moving while it was ahead. Keep moving on the UltraSPARC chips... innovate... be the best of the best. But in the end, clever people with commodity hardware have essentially put Sun in the position of an also-ran, and that's sad.

Like when I heard SGI was filing Chapter 11. Sad.

So I've emailed Steven C. at SunFreeware and asked him what it might take to build OpenSSL and zlib and curl for 64-bit on Solaris 8 and 10 SPARC. I expect that it'll be more than I want to do at this time. It's getting harder and harder to justify Sun hardware when I can get an 8-core x86_64 box with amazing speed for next to nothing. Cost will drive the market.

I'd love to keep working on Sun, and I'll never get rid of my SPARC 20, but I can see a time very soon that work will be driven off linux, and it's a solid platform that I've enjoyed using for years. It's just too bad that Sun was in the lead, and they stood still.

UPDATE: I've received email from Steve of SunFreeware that the most recent versions of Solaris do have things like OpenSSL, zlib, and curl in 64-bit as part of the install. If that's the case, then I'm happy for Sun, but a little disappointed that it wasn't made backward compatible in the sense of Solaris 8 and 10.