Friday May 26, 2006

Xinerama

Last weekend I was installing a Xinerama system using a Matrox G450 dual-head card. Hey, $15 at TigerDirect, what do you want more. But it's not the price that this topic is about, it's probably even not Xinerama that it's about. When you install a dual-screen system – doesn't matter if it's Windows, Linux or Solaris based – you simply get a display twice as wide, with the result that among all other problems the pop-up window appears in the center. Oops, that center is where you have those two chunks of beige plastic, which is called the case of your monitor :-).

In some situations this concept of an extra-wide screen is maybe useful, but IMHO in most it is not very apropriate. I've noticed that more recent Xinerama versions have become more intelligent when it comes to pop-up's, but still I think that taking two screens as just a single extra-wide one is not the right choice.

Let's take a step back. Having a second display is not so much having a bigger screen, but much more similar to the multi-window feature X-Windows display managers have since a couple of years. It's also more like what in the old days you could do on a 80x24 display with Alt-F1, F2, F3 or F4, just switching from one screen to other. I think it is even very similar to what a tabbed browser like Mozilla / FireFox provides you. So yes, it is a second screen, but that doesn't automagically make it into a wider screen.

Now I know that I can solve the "popup in the middle" problem by having a third screen, or maybe five <g>. The popup then again appears centered, but that's beyond the point. Many desktop users like multiple screens, but most don't use them as one large canvas. It's most often something like "let's keep my email open on the right, while I keep working on the main screen". Notice the phrase "main screen"!! It's time to have an alternative to Xinerama, very similar to the multi display feature in X-Windows, controlled by the bar/panel at the bottom. I think the display needs to be more distinct, the mouse will not move "out of bounds", but still you can drag a window to another display.

For me, that would be a much more natural user interface. And maybe it does exist already (most things do :-) and I just haven't found out how to configure it in X-Windows. If not, it's probably time for me to start a little X-Windows hacking project ... ehhh, probably not so 'little'.

Thursday May 11, 2006

Solaris X86 real-time clock

Having enough Unix blood in my veins – be it Solaris, BSD, Linux, AIX, Ultrix, Xenix, SCO, whatever – when I install Linux on a PC I always configure the CMOS clock to be running in GMT. When that system runs Windows too, it's maybe not too wise a choice, but the purist in me likes the Unix method of having a UTC based real-time clock.

Here I have to side step for a bit and give air to a personal rant: Why on earth (very literally in this case) are calendar systems, especially on PDAs, not able to schedule meetings in a different timezone than where you are. And in addition keep track of the timezone you're in. Even if you're not a road warrior, con-calls are attended from many zones. It gets worse, let's say you are in EST when you schedule the con-call, and after travelling from EST to CST you attend. By now your calender has become a complete mess. That's why PDAs should use the Unix method for storing dates and times. And the applications of course need to change.

Back to our notebook with that combo of Windows, Linux and Solaris. With two-out-of-three winning here :-), I always configure the real-time clock to run in UTC. Of course you have to be careful that Windows isn't syncing with an NTP server. Still I had problems with the time on my system and I must admit that I blamed that fully on Windows. Which is not true ... but also true.

Investigating this a bit more systematically and reading the appropriate man pages, I discovered that Solaris X86 assumes your real-time clock to run in local time. This, because Solaris also assumes that it has to co-exist with Windows. Therefore, if you read the manpage for /usr/sbin/rtc and look in the file /etc/rtc_config, you will see that it stores the seconds between the local clock and UTC to take care that when the CMOS clock runs local-time, the Unix kernel can run in UTC and then the normal Unix TZ mechanism is used so that date/time info gets displayed again in local time. In my opinion this is really to Take The Long Way Home, but that's how it is.

#
#       This file (/etc/rtc_config) contains information used to manage the 
#       x86 real time clock hardware.  The hardware is kept in the machine's 
#       local time for compatibility with other x86 operating systems.  This 
#       file is read by the kernel at boot time.  It is set and updated by
#       the /usr/sbin/rtc command.  The 'zone_info' field designates the local 
#       time zone.  The 'zone_lag' field indicates the number of seconds 
#       between local time and Greenwich Mean Time.
#
zone_info=Canada/Mountain
zone_lag=21600

I didn't test it, but I presume this gets updated on-the-fly at the start and end of Daylight Savings Time. Bottomline is that whether you like it or not, the CMOS clock must run in local time and that you must configure your Linux installs accordingly.

Tuesday May 09, 2006

NVIDIA nForce 3 Ethernet

At home, I'm using those little black Shuttle SN85G4 systems. One as my desktop and one as a MythTV project under way, which has to be ready by the time the soccer championship hits us in June. These Shuttles are running AMD64 (socket 754, no Opteron's :-). They're small, pretty silent and because Shuttle is coming up with new stuff, you get them pretty cheap, if you're still able to find them.

This weekend I was installing Solaris 10 and stumbled on the nForce 3 chipset not being supported. Also no download available from NVIDIA (for Linux yes, not for Solaris). That gives you a system with no working NIC, and that's no good. Checking the HCL, they clearly took the "easy way out" by installing a separate PCI network card, by-passing the onboard NIC.

A little browsing brought me to Masa Murayama's website which brings a whole set of unusual and therefore so useful NIC drivers. Among those, one called "nfo" for the nForce chipset. Masa labels the driver alpha-code, but I've had no problems. If you're going to use this driver, here are some tips. The tarball contains the source, but also ready-to-go modules for i386 and amd64. You can try to build, but if possible, better don't. Forget about "make", jump straight to "make install". I'm saying this, because building with gcc needed a little hacking and compiling with Studio 11 wasn't successful at all.

Next, follow his README carefully. It includes an "install", then an "uninstall" and then again an "install". This sounds weird, but if you follow it strictly, it all works. If you try to make shortcuts, like I did :-), you better know what you're doing, I didn't :-).

I stumbled on one problem. Part of the install is running a script called "adddrv.sh". In my case that gave a message about a library already being installed. I took that as a warning, but it really was an error. You have to solve that (by commenting out a line in the script, in my case two lines) before you can continue. If you ignore it, you're in trouble, it won't work.

When I later emailed about this with Masa Murayama, he mentioned that the likely cause was an nForce GbE driver recently added to Solaris. I guess he is right about that, but for me he is "1 - 0" ahead of the game (we're back to soccer here :), because the standard install didn't give me any networking at all and his "nfo" driver is doing fine.

Tuesday May 02, 2006

Sun Desktop Manager 1.0

May 1st, Labour Day. Isn't that a nice date for my first article on BigAdmin. A small part of today's Network Computing Event, was the release of Sun Ray Software 4. Which includes Sun Desktop Manager 1.0, formerly aka APOC. The latter originated in Sun's JDS on Linux, but the current SDTM is targeting SunRay and Secure Global Desktop.

With Sun Desktop Manager you can store and manage the configuration of a user's desktop (his Gnome preferences, his proxy server, his Mozilla's home-page) in a central directory. The cool thing about this is that because a directory has an hierarchical structure, you can enter these settings not just for the individual, but for whole departments at a time. Or the hierarchy can be based on your network topology, or even both. Desktop Manager will also allow you to lock down desktops by disabling entries in the Gnome start-menu.

I could go on and on about the cool features of this system, but that's not the topic. In the last two years I helped quite some customers with setting up POC's. A stumbling block for many of them was always the lack of knowledge on how to configure the LDAP server. The folks that created SDTM always assumed that people would know that, but working in the field you realize quickly that that isn't always the case. I did some beta-testing of SDTM 1.0 and converted my ldif files from the old APOC to the new SDTM. And then decided to "finally" figure out how this could be done without some magic ldif files, but just with the available Directory Server console tools.

While doing so, I captured screenshots and glued the whole thing together into a step-by-step guide on how to set this up. And that resulted in this BidAdmin Feature Article with the name "Sun Desktop Manager Tutorial". It will be referenced from the SDTM product documentation, when that's released on May 16th.