Thursday Aug 12, 2004

SunRay Server 3.0 Beta available for download

As Jason Shroeder's Weblog points out, SunRay Server 3.0 beta is now available for download here. It runs on Linux or Solaris and has low bandwidth requirements (300kb/sec), which makes it possible to run it over broadband. I've been using it for a while now.

Wednesday Aug 04, 2004

On second thought: Tadpole Comet would make a nice iWork client

O.K. a powerful 64 bit workstation might be overkill for some iWorkers. Thanks Dan for pointing out another iWork option: The new low bandwith SunRay protocol over DSL with one of these cute little Tadpole Comet thin client laptops. Since the battery doesn't have to run a space heater and cooling fan or peltier device, this Tadpole can get 6-8 hours off a single battery! This would be great for libraries, schools, businesses and eventually for the rest of us. (When the world is "wired" for WiFi.)

If a thin client future sounds unlikely think of this: Broadband and WiFi bandwidth continues to increase while thin client bandwidth requirements decrease. Also the same thing happened with audio communication. While you could use a powerful 1000 Watt amateur radio or 4 Watt CB radio to wirelessly contact a neighbor, most of us find it more convenient and reliable to use a 0.25 - 2 watt cell phone and let the network do the work. Sure there will still be power users with thick clients in their bedroom just as there are still radio hams and muscle car enthusiests. But I'm writing this blog from a SunRay1 thin client on a 100MBs ethernet and for most applications it already feels much faster than my 2.8 Ghz P4 laptop.

Friday Jul 30, 2004

Blogging from StarOffice 7 and the awesome speed of a V20z

The Sun blog redirect site appears to be inaccessible from Ireland at the moment so I'll try writing this blog offline. One recent blog complained about the dearth of good blogging tools and a comment suggested OpenOffice. A full featured word processor might be overkill, but what the heck I'll try blogging in StarOffice 7 and see how pretty its XHTML export is. Hmm, it looks kind of weird, not as pretty as plain text but I'm going to publish it anyway, for the sake of science. I'd forgotten that StarOffice now has the option to save a document as simplified docbook xml. That could be useful someday.


O.K. maybe it sounds like I'm trying to hype something again, but I really am enjoying having a 2 CPU Sun Fire V20z all to myself! Actually there are a couple of users logged in but they don't appear to be be doing much. Give me a couple of 2.1GHz 64 bit CPUs each with 1M level 2 cache add a few gigs of RAM and I won't even touch the 6 gigs of SCSI swap space, unless I'm editing 32000X16777 images for a GNOME Jumbotron theme or working on my daughter's 8960X6720 photo mosaic. How long would a 90 degree clockwise rotate of this image take? How about a 5 pixel IIR gaussian blur or a bicubic scale down to a 500X375 web sized image? About this long:

baby mosaic

Yes, my wife and I do take a lot of photos! Who came up with this 4095Mb limit anyway? Was it the same person who came up with the limits of 1.99G, 504Mb, 640kb, 64k... In any case you won't run into many limits with this box and it's really snappy and not too pricy. Unfortunately, we don't have room for a rack in our living room so if I were in the market for a new computer, I'd probably buy one of these slick new Sun Java workstations instead. My wife did notice that the V20z is quite a bit faster than any machine we've ever used and my daughter was most impressed by da's keyboards, monitors and swivel chair, but it would be difficult to convince them of the absolute necessity at the moment. So Scott, can I have one of these for iWork? Does it come in a laptop?

Fun Image Processing and Mosaic applications

Duncan asked me what program I used to create this photo mosaic. I used an excellent free application called MacOSaix Thanks Knarf! MacOSaix sorted through about 5000 photos on our 400mhz pismo powerbook. I don't remember how many hours it took, but I started it one evening and my wife was still watching the computational tetris the next afternoon. Poor little powerbook, if only I could run the mosaic building application on this V20z!

Well it turns out that there is an alternative mosaic sourceforge project called Jimage-mosaic Jimage-mosaic is written in Java so you should be able to run it under Linux, Solaris, Windows or MacOSX. I should be able to run it on the V20z if I have time before I have to return it :-(

Another favorite scientific and medical image processing utility is ImageJ ImageJ is also written in Java and I've successfully run it on MacOS, Solaris, Windows and Linux.

Last but not least in my 2D imaging pallete is a free open source multiplatform imaging and retouching program called The Gimp. This was included as the image editor in Sun's Java Desktop. Videographers and cell animators would appreciate a branch off the Gimp project called CinePaint. Along with the usual gimp/Photoshop features, CinePaint has up to 32 bits of color per channel! (up to 128-bits RGBA) A frame manager (with an onionskin overlay feature for cell animation!), motion picture file formats and a flipbook player.

Thursday Jun 10, 2004

Are there really GNOMEs living inside my desktop?

I'm sure many have experienced this problem, you're working on your favorite application under your favorite OS when suddenly...chatter clatter chatter, the drive light blinks furiously. Or maybe there are no physical signs, but the system suddenly inexplicably grinds to a crawl as if the bits somehow encountered the computational equivalent of molasses. You manage to run `top` only to learn that the top cpu user Whatever it is either doesn't take up CPU resources, or does it in such a way that isn't easily measurable. A few seconds later everything suddenly goes back to normal and all is as though the strange occurance never happened.

Not long after GNOME 2.0 was deployed on internal SunRays, one of our engineers impressed me with the diagnostic capability of a new tool called dtrace in finding a problem which somehow escaped many opensource eyes and found its way onto many linux and Solaris desktops. When the desktop group brought JDS to Solaris it provided an opportunity to learn more about these mysterious GNOMEs. So I installed a JDS build on Solaris 10 beta and ran the dtrace tool on a bare GNOME desktop with only a couple of terminals, a panel, a nautilus window and mozilla. I started by looking at reads and writes. After all, though CPUs have become hundreds of times faster in the past 20 years, hard drive latency hasn't changed nearly as much.

A few words about dtrace. Software developers are familiar with the technique of peppering their code with printfs and enabling these with build flags or environment variables. But what if the OS maintained a database of probes that you could turn on or off at will? Dtrace provides this capability. So I ran a little dtrace script in the d language which looks at how many times each process is invoking the write system call:
 @counts[execname] = count();
I ssh into the machine, start the dtrace write script and then go away to a meeting. When I return I can see what my desktop was doing while I was away:
  dtrace                                                            1
  sshd                                                              4
  sac                                                              10
  ttymon                                                           10
  gnome-panel                                                      55
  mozilla-bin                                                     636
  xscreensaver                                                    663
  clock-applet                                                   2971

I run a similar script on the read system call:

  sh                                                                1
  ttymon                                                            4
  sac                                                               4
  nscd                                                              5
  dtterm                                                            5
  init                                                              8
  utmpd                                                            10
  gnome-session                                                    10
  nautilus-throbbe                                                 10
  gnome-smproxy                                                    17
  sshd                                                             24
  gnome-settings-d                                                 30
  clock-applet                                                     32
  nautilus                                                         83
  wnck-applet                                                     125
  metacity                                                        151
  mozilla-bin                                                     225
  gnome-terminal                                                  234
  xscreensaver                                                    275
  gnome-panel                                                     287
  gnome-vfs-daemon                                                657
  Xorg                                                           5771
I'm also interested in calls to open. To look at these, I download a dtrace script called opensnoop.d from the dtrace tools repository. It looks like gnome-vfs-daemon and sshd are the winners. sshd is opening /dev/random and gnome-vfs-daemon is opening /etc/fstab and /etc/mnttab. I'm running over an ssh terminal session and letting the output go to the terminal so I'm causing a bit of a probe effect. So far I've only looked at a quiecent desktop. I'll run a script tonight to capture more information, but then I'd like to find out how a GNOME desktop behaves when it is being actively used. Stay tuned...

Wednesday Jun 09, 2004

It usually works

One of the other Sun engineers titled his blog "sometimes it works", there are some bugs that almost never occur, but when they do occur they are just as vexing. Such intermittent problems can be extremely difficult to track down. Here are two examples of bugs that appeared only about once every 10-30 reboots on a customized Java Desktop System 2.0. The first bug presents the GNOME user with login failure and a "your session has lasted less than 10 seconds" message, about once every 10-30 reboots. Here are some details:
Xlib: connection to ":0.0" refused by server
Xlib: No protocol specified
/usr/bin/X11/xsetroot:  unable to open display ':0'

...  (None of the clients can connect to the xserver)

The logs in /var/lib/gdm show:
AUDIT: Fri Jun  4 15:48:27 2004: 1631 X: client 3 rejected from local host
AUDIT: Fri Jun  4 15:49:56 2004: 1631 X: client 2 rejected from local host
Further investigation showed the root cause of this. The problem occurs in the following circumstance:
  • The computer boots with a preconfigured hostname.
  • (xdm)generates an .Xauthority file with a magic cookie for this hostname.
  • The DHCP client asks for an IP address and a new hostname.
  • The DHCP client changes its hostname.
  • The user logs in, but now the hostname doesn't match the previously authorize one so none of the clients can connect to the xserver. NOTE: Xauthority is a mechanism for assuring that only authorized clients can access a display.

    A janatorial problem caused the second intermittant bug. The underlying linux distribution (SLED) does not clear the /tmp directory between reboots. Some processes create sockets in /tmp/.ICE-unix with the name of the process id. Unfortunately, after a reboot it is possible (in fact likely) to have a new process with the same pid as a long dead process. Because /tmp/.ICE-unix hasn't been cleaned out, the unlucky process can't create a socket with the name of its PID because the name already exists. Again, the symptom is an intermittent login failure.
  • About



    « July 2016