I know I've been pretty silent lately, but I've been all wrapped up getting my new Linux desktop configured. As an example of my progress, here's a screenshot of R5 running on Linux using Wine (click it for a larger image):

I was having trouble getting Notes 6.5 to work, but then I read Peter Leugner's recent post on LDD and realized that I'll probably have to upgrade to 6.51 to get that right. I've been meaning to do that anyway...

My wife and I have been talking about using separate computers. No, it's not like wanting separate vacations or separate bedrooms; rather, it's just a practical matter based on the fact that we both have our primary applications on the same machine. Not good for her if she wants to get on the computer after the kids go to bed, because I usually stake a claim to it pretty early in the game, and I can box her out with Shaq-like effectiveness.

If money was not an option, I'd just buy a honkin' new machine, but I just can't justify it right now. I've got a couple other slightly older but perfectly usable computers in the house that would do the job.

After much internal debate, I decided to let my wife have the computer we've been sharing (since it's already got everything on it, and it works just fine), and I rebuilt a Pentium 700 MHz computer (formerly running Windows 98 -- bleh) using...Fedora Red Hat Linux.

I'm trying to treat this as an opportunity, since I've really been wanting to attempt to use a Linux machine "full-time" for a while now. I've dabbled in Linux for many years, but it's always been just a fun little hobby. Just something I had running on a separate machine that was fun to goof around with. Like anything else, you don't really learn something unless you use it and live with it every day. So I'm going to try to take the plunge.

The only thing that really scares me is Notes client support. I know that plenty of people have had success with Notes 5 in Wine, and rumor has it that ND 6.5.1 runs in Wine as well, but I guess I'm just concerned that if I run into a problem with a database, I'll have a hard time knowing whether it's a problem in Notes or a problem in Wine. I guess I'll see. If it gets too hairy, I can just shell out the bucks for VMWare Workstation (which is much more affordable now that they have to compete with Microsoft Virtual PC pricing).

Anyway, after I kicked the tires on several distros, I decided to use Fedora Core 1. I like the layout, I have an easy time finding commands and programs that I need, I can use up2date and/or yum for patch management, and the Fedora user community seems quite active (which should mean good support). I played around with Core 2, Test 2 for a brief time, and I liked it but I was worried that I might run into problems. Maybe after it goes gold I'll consider an upgrade.

The install took an hour or so, and everything got recognized and loaded properly. Boy have the Linux installs gotten easier over the years. I plan to share my experiences with all of you -- there should be plenty -- but probably not here on this blog. I'll either do a separate blog for that purpose, or I'll set up some kind of cluster of pages with an index. I'll let you know.

In the meantime, wish me luck!

I was skimming the Domino 7 Beta Release Notes today, and saw that there were a couple items in there about new debugging options. First, there was this about Java debugging:

You can debug Java agents, Web services, script libraries, or any Java code running under control of a Domino server JVM (Java Virtual Machine) with a debugger that supports the JPDA (Java Platform Debugger Architecture), such as Eclipse. See java.sun.com/products/jpda for information on the JPDA. See www.eclipse.org for information on Eclipse and the Eclipse debugger. You cannot debug a Java agent running on a Notes client. Only one user can debug at a time.

Hopefully they'll work out the details of debugging from the client by the time the product goes gold. They're shipping with Java 1.4.1 as well, which is a nice step.

I also read this about LotusScript debugging:

The toolbar now contains an icon for enabling and disabling LotusScript debugging. "LotusScript debugging started" and "LotusScript debugging terminated" messages now appear on the status bar rather than in a message box.

Ah, no more debugging started/terminated dialog boxes. Mike will be so happy. Heck, I think we all will...

Last week we had an IBM rep come down for three days and help us set up a WebSphere Portal demo environment -- not a dinky little Portal Express server like I was playing around with before, this was a full-blown install of Portal Express Extend. It's way too early to give you any kind of reactions to Portal itself, but I can certainly toss out a few opinions on the setup and configuration process.

1. Use VMWare if you can
Nuff said about my opinions on this in the previous blog entry. VMWare will just make it a whole heck of a lot easier to set up, manipulate, resize, and (potentially) rebuild your test environment.

2. Give yourself a full three days for the install
No joke. You'll want to have at least three entire days to perform this task. This will give you time to do the install itself, the configuration of the environment, and any troubleshooting that becomes necessary (unless you're extremely lucky, you'll definitely be doing some troubleshooting). Granted, my three days also involved building a Sametime server, a Quickplace server, and a very basic Domino LDAP setup, but those installs are actually pretty quick if you know what you're doing.

3. Do your best to involve IBM in the installation
The IBM rep who assisted with our install was invaluable for two reasons (well, probably more than two, but I'm trying to keep this short): he had access to some very technical people when we had questions or problems, and he brought along the not-yet-released WebSphere Portal 5.02 Install Guide. If you can't involve IBM, you at least HAVE to have the install guide. It's not available on the IBM site yet, but if you need it then Joel Demay posted a slightly older version of the guide last month. Not sure what the differences are between the one he has and the one I have, but it's at least a great place to start. I can't tell you strongly enough how much you need this guide for the install.

4. Use the biggest server you can get your hands on
The server we set up (Windows 2000) idles at anywhere between 600 and 900 MB of memory usage, depending on how much use it's had recently. Granted, we did the "all in one" setup (database, HTTP server, WebSphere App Server, and WebSphere Portal Server on the same machine), but even if you distributed the load across a few boxes it's still a demanding application. That kind of resource utilization isn't unheard of -- heck, my Sametime server idles at about 800 MB of memory use -- but you need to be acutely aware of it when you're setting up a test environment. None of this "oh, we're only testing...just use that old server in the corner" attitude. You want a manly machine.

5. Use the operating system you're most familiar with
A couple weeks before the install, I spent a little time researching performance benchmarks of WebSphere on different platforms. I actually found nothing that was either recent or authoritative, but in retrospect it really didn't matter. Even if it ran twice as well on Linux (which is not unheard of: see this Quickplace scalability test for some jaw-dropping results), Windows 2000 was the correct operating system to use in our test situation. Why? Because that was the environment we were most comfortable in, and that was what the install guide was written for. From the troubleshooting standpoint, it was a whole heck of a lot easier to poke around on the Windows machine. From the support standpoint, it was much easier to find people with Windows expertise who were willing to answer questions.

Now, for a production server (once you feel comfortable with your test system), you owe it to yourself to do some research and perfomance testing if there's even a chance that you'd be allowed to put a non-Windows server in your environment. UNIX-type systems have a tremendous capacity for performance tuning, so the research and testing might pay off big in the long run. When you're just evaluating the software though, making it fast is second to making it work in the first place.

(NOTE: please understand that everywhere I'm saying "test" server above, I really mean "evaluation" server. Once you get any kind of production system in place, you should always try to have a test system that mirrors production as closely as possible. I know that, thank you very much. I only point that out because I almost got into an argument recently because I was talking about setting up Portal on a "test" system, and I meant "evaluation" but the person I was talking to thought I meant a "test-QA-production" scenario, and...well, we weren't seeing eye to eye.)

I'm still resting from last week's install of WebSphere Portal. I'll try to tell you all about it later this week, but before I start I want to say how impressed I am with VMWare.

For the WebSphere testing that we're doing (which involves a Portal server, a Domino Quickplace server, and a Domino Sametime server), the guy who builds and manages servers at our location decided to do the Windows 2000 installs onto a couple of VMWare ESX boxes. I had only heard of/seen VMWare before as a tool for developers who wanted multiple operating systems installed on their machines for "development purposes" (which often meant "just for fun", but whatever), but never had any experience with it on the true server side.

From what I saw over the last week, I feel very strongly that servers set up as virtual machines are the future of the data center.

Let me start by saying that I realize that the virtual machine concept has been an integral part of mainframe and AS/400 technology for a long, long time. I respect that, and I'm not trying to take anything away from that proud and established history. However, most data centers now are rife with Windows servers, and every time you need a new Windows server-based application you have to throw another box in the rack. With that mentality, those data center racks multiply like rabbits.

In the VMWare world, you can set up a whole slew of virtual machines on a single server, so instead of setting up several mid-sized machines to host your individual applications, you only need a single (slightly beefier) VMWare machine to host them all as their own VM's. After all, most app servers average very little processor and memory use, so throwing them all on a single machine simply makes better use of the processors and memory you have available -- in fact, one of our admins in a remote location took 8 Windows app servers and moved them to 8 virtual machines on a single VMWare server, and the users didn't even notice.

But to me, the real value of the VMWare model is the way that you can backup and move entire operating system environments. For example, for the WebSphere Portal test box, our server engineer started by loading Windows 2000 on a virtual machine, getting all the security and settings in order, and loading all the service packs. Then he copied that image off as a backup. If we had screwed up the Portal install and had to start from scratch, all he had to do is load a copy of that image up and we could start right over. And it's not like Ghost (or any of the PC-types of imaging programs), where all the individual files have to be decompressed and copied onto your system, and you have to have all the right drivers and everything. The VMWare image (as I understand it) is just one big file that you enable for that particular virtual machine.

And then he was telling me that if we needed to move that virtual machine to another server, it's essentially the same process. Because VMWare is the interface to all the hardware on the physical server, there are no drivers to worry about -- all you do is move the image over and turn it on. Wow! So let's say you've been running 8 Windows 2000 servers as virtual machines on a VMWare box for a few years, and it's time to upgrade the server. You just load VMWare on the new server and scoot all the VM's over when you're ready. That would be about the easiest server migration you've ever done. If you were operating off a SAN it would be even easier. And if one of your 8 virtual servers has outgrown the VMWare box? Just look for another VMWare server that's less crowded or more capable and move it over there. Need a test server for a couple weeks? Find an available virtual machine on one of your VMWare boxes and dump an image on it.

I know I'm going on and on about all this, but I can just see so many possibilities here. Smaller, more condensed data centers. Easier backup and recovery (and fail-over). Simplified server migrations. Dymanic server sizing (because you can allocate as much or as little memory to a virtual machine as you want). All that stuff that people have been doing on the big iron mainframes for years, but now you can do it with little bitty Windows servers too. And you can even have your Windows and Linux virtual machines running side-by-side on the same box if you'd like.

But what about performance, you ask? I got exactly the same performance out of my virtual servers that I would have expected from "regular" Windows 2000 servers. I've even heard that some people have reported better performance from Windows virtual servers over their non-virtual counterparts, but I haven't seen any objective tests to back that up.

I will say that CD-ROM access was pretty slow, so if you're going to install a big application onto a virtual server from CD, you might want to copy the CD down to the hard drive first. I also noticed a positive difference in speed on the virtual machines when I disabled all the COM ports and LPT ports, along with disabling auto-play/autorun on the CD drives (apparently this gets rid of a lot of hardware polling or something). You can do this by:

• Right-click the My Computer icon on your virtual server and choose Manage
• Go to Device Settings and expand the Ports entry, then right-click each of the COM and LPT ports and choose the "Disable" option
• To disable CD autoplay, open Regedit, go to HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer and set the value of NoDriveTypeAutoRun to 0xff (if you're afraid if the registry, you can also run gpedit.msc and disable it from Computer Configuration - Administrative Templates - System)

Our server engineer also said that he had to play with the initial virtual machine memory settings to keep the performance metrics in the "safe zone". Apparently VMWare will recommend a certain amount of memory to allocate to all of the virtual machines on the box, but we seemed to get better performance by reducing the memory allocation to a little less than the recommended amount (maybe 5% or so).

Okay, sorry about the long blog entry there. I just wanted to get all that off my chest. I thought it was all pretty cool.

Boy, it's been almost a week since my last blog entry. Sorry about that. I've been trying to immerse myself in WebSphere Portal at work because we've got IBM coming down tomorrow to help us with an install, and at home I've been doing a little skunkworks project that I'll probably tell you about next week.

Along the WebSphere lines, I just posted a tips page outlining my recent struggle getting WebSphere Portal Express installed. You can find it at: WebSphere Portal Express Install Tips

That's about 20 hours worth of install experience all rolled up into a single page. Maybe I was just doing something horribly wrong, but that whole thing was just a painful undertaking. I guess I learned a lot though...

I've been reading a lot of comparisons between Microsoft and Linux in the news lately, many of which seem to be saying that "independent sources" are declaring Windows to be faster or more secure or cheaper than Linux. Here are a couple of reactions to those comparisons from the Linux side of the house:

Getting the Facts About Windows and Linux
Latest Linux/Windows research reports queried

You probably won't see links to those articles pop up in your Yahoo news list, so consider yourself informed.

For the past few weeks, I've been piecing together a new tips page for your enjoyment. I think I'm finally happy enough with it to let you take a look. The new page is: Notes Performance Tips

It's possible that I didn't write anything you haven't seen before, but I at least wanted to put it all in one place. Even if you know all of those things already, seeing it in a list like that could remind you of something you may have overlooked. Some of the links might be pretty useful too.

This weekend is the start of daylight saving time in the U.S. (that's "saving", without an "s" on the end). I'm pretty sure that people almost universally think that daylight saving time is weird. I know I do, and it's hell trying to get the kids to adjust for the first couple weeks.

If nothing else, it's just confusing, even to the point that different parts of the world have different schedules for the start and end of daylight saving time, so Australia just came off of theirs and the U.K. started last weekend, and a few places in the U.S. don't recognize it at all. In fact, some parts of Indiana recognize DST and some don't. Combined with the fact that Indiana is in two different time zones, knowing the proper time of day can get pretty crazy in that state.

I found a pretty good daylight saving time reference the other day, and as I was reading through it I learned yet another strange thing. In the United States, the Department of Transportation has jurisdiction over daylight saving time. I have no idea why. Maybe it had to do with railroads a long time ago, or commerce.

Not that it really matters who's responsible for it, I suppose. I can't imagine that the regular daylight saving time staff meetings are very exciting. "All in favor of doing the daylight saving thing again this year say 'Aye'... All opposed... Okay, meeting adjourned." It's probably just all the fan mail that keeps them busy.