Why should we care about basic research?
by Mike Uchima — 12:05 PM on May 29, 2008

I was surprised to learn today that my former employer Fermilab (I worked there until about 12 years ago) was given a temporary reprieve this week from rounds of rolling furloughs and mandatory layoffs, when an anonymous donor gave them $5 million dollars. While I applaud private sector support of basic research, I find it sad that one of our premier research institutions is in effect reduced to living hand-to-mouth, off of the kindness of strangers.

Cutting-edge basic research is a big factor in attracting bright young minds to science, and it pays huge dividends even when there are no obvious direct applications of the basic principles being studied. Fermilab (and the field of high energy physics in general) has made significant contributions to many fields of science and technology. The construction of the Tevatron required breakthroughs in the fields of cryogenics, superconducting magnets, electronics, and other related fields. There is a nuclear medicine research facility on site, which conducts research into cancer treatments based on the use of high energy neutron beams. The group I worked with did leading-edge work in massively parallel computing and clustering, which have replaced traditional (and far more expensive) supercomputers in many applications. Fermilab even supports research on the restoration of native prairie habitat at their Batavia, IL site. And lest we forget, the very World Wide Web that you are using to read this article is a product of the high energy physics community, having been invented by Tim Berners-Lee at CERN in 1990! (And that's just the stuff I could think of off the top of my head...)

By cutting back on basic research and not putting a greater emphasis on scientific literacy in our elementary and secondary schools, we are selling our future short. We are already at significant risk of ceding technological superiority to our foreign competitors. Most of our manufacturing has already been relocated to Asia. 20 years from now, will most of our R&D be outsourced as well? I am starting to think so. Even Bell Laboratories—for decades a symbol of technological prowess, and inventor of the transistor and the C/C++ programming languages, among other things—has fallen on hard times; the smoldering hulk of what's left of Bell Labs has been acquired by French telecommunications conglomerate Alcatel, and continues to shed employees at a rapid pace.

Allowing Fermilab—once one of the crown jewels of the US national laboratory system—deteriorate to the point where it is practically on life support is, quite frankly, a disgrace. This isn't just about some scientists working on esoteric research projects losing their jobs (which, while certainly tough for those being laid off, is no worse for them than what goes on in the corporate world every day). It is also a barometer of our collective attitude towards science and the pursuit of knowledge, and I believe it has broad and far-reaching implications for the future of Western society. Are we losing interest in asking the big questions, and (as a result) also losing the skills required to answer them? I believe our competitiveness in an increasingly global market, and ultimately our very way of life are at stake.

38 comments —
Last post by iDenTiTy at 2:17 AM on June 25, 2008

Ubuntu 8.04 field notes
by Mike Uchima — 1:33 PM on May 15, 2008

As I mentioned in one of the comments I posted in last Friday's FNT, I was planning on taking a laptop running Ubuntu 8.04 on a business trip this week. Well, here I am in Tuscon AZ... and this is Day 3 on the road with Linux!

Ubuntu pre-installs a reasonable set of desktop applications. Firefox, OpenOffice, Evolution (an Outlook-like e-mail client), Rhythmbox (music player), etc. are all there by default. Before leaving, I installed and/or configured the following additional applications:

• Thunderbird. I prefer Thunderbird to the default Evolution e-mail client, so I installed it from the Ubuntu repository. Installation and setup were uneventful, and Thunderbird worked just like I am accustomed to on Windows.
• Amarok. IMO much nicer than the default Rhythmbox music player. This installed without incident from the Ubuntu repository. (I should point out that Ubuntu also detected the sound hardware on the laptop and installed the correct drivers without any input from me.)
• VMware Server 1.0.5. I needed this application for the trip. VMware Server was not available from the Ubuntu repository (since although it is free, it is proprietary commercial software), so I downloaded and attempted to install the Linux version from VMware's web site. This one was very nearly a train wreck. I did get it working eventually, but it involved a lot of Googling, and the installation of a third-party hack to make it compatible with Ubuntu 8.04. And the system clock in the virtual machine goes nuts whenever SpeedStep kicks in; this doesn't just affect the time-of-day clock, it causes the whole guest OS to behave oddly (so I have to disable SpeedStep whenever VMware is in use). To be fair, these are probably as much VMware's problem as Ubuntu's...
• Remote Desktop (actually called Terminal Server Client on Ubuntu). I needed this to be able to remotely access my Windows XP desktop at the office in case I needed any files that were not on the laptop. This is installed by default, so I just needed to test it. I had one minor glitch—full-screen mode does not play nice with the compositing window manager (compiz) now used by Ubuntu. After some Googling, I came up with a fix (disable "Legacy Full-Screen Mode Support" in compiz).
• VNC viewer, to view remote Linux desktops. Installed from the Ubuntu repository without incident.

During my initial setup and checkout of the laptop, I noticed something really annoying. It seems that in its default configuration, Ubuntu 8.04 has serious problems dealing with the lid of the Compaq nc6220 laptop being closed and reopened. CPU usage zooms up, the system becomes very sluggish, and stays that way until the next reboot. A bit of Google-fu eventually revealed that some other laptop models are affected as well, and that there is a workaround (a tweak of the video driver that tells Ubuntu to allow the BIOS to manage the LCD backlight instead of trying to do it itself). Although I was able to work around the issue, glaring problems like this can give people a negative first impression; I hope Ubuntu fixes this soon with a patch.

Once here in Tucson, I was pleasantly surprised to discover that Ubuntu detected and connected to the hotel Wi-Fi access point seamlessly. The wireless chip in the laptop had been detected automatically and the proper drivers installed during system setup, with absolutely no intervention on my part. Installation and setup of Skype was also uneventful (though the download of the package from Skype's site was painfully slow over the hotel Wi-Fi connection).

Although I had forgotten to install Skype before leaving, I did have the foresight to drag along a snapshot of the entire official Ubuntu 8.04 repository (all 50+ Gb of it on an external 2.5" hard drive), to make installation of any additional software from the repository faster. I figured the less I had to depend on the hotel Wi-Fi connection for downloading packages the better. After arriving, I also installed the following, all without incident:

• Bluefish. I'm still trying to decide what text editor I prefer to use on Linux, and figured I'd give this one a spin. Looks pretty reasonable so far.
• Mediawiki (and MySQL). I need to do some work for the office Intranet site, and decided I'd be better off doing it offline and uploading the content to the server when I arrive back at the office than trying to do it all remotely. (This decision was partially due to the lack of connectivity while on-site, more on this in a moment.)

We initially had no Internet access while on-site; so Monday afternoon we picked up a Verizon 3G wireless modem. With the Verizon modem connected to a Windows XP laptop running ICS, and my Ubuntu laptop wired to the XP system via their Ethernet ports, both systems were able to access the 'net. (I have not yet attempted to get the wireless modem working on Ubuntu directly; that's an experiment for another day.)

So overall, I'd say Ubuntu 8.04 has worked reasonably well. The issue with the laptop lid switch was troublesome until I figured out how to work around it, and the VMware installation issues were annoying (but are likely at least partly VMware's fault). Everything else I've tried to do has pretty much just worked.

So is Linux finally ready for the desktop? Based on the past few days, I would have to answer with a qualified "yes." Depending on your needs, Linux can definitely be a viable alternative to Windows. I also plan to install Ubuntu 8.04 on a desktop at home within the next week or two. For years, Linux desktop proponents have been like long-suffering Chicago Cubs fans who have been waiting 100 years (and counting...) for a championship. The mantra of a true Chicago Cubs fan is "Just wait until next year!". For desktop Linux, I think "next year" may have finally arrived.

 

98 comments —
Last post by vorgusa at 1:09 PM on June 25, 2008

40-year-old toy meets modern scripting language
by Mike Uchima — 12:13 PM on May 1, 2008

As a kid, one of my favorite toys was my Spirograph Set. I had the original 1960s version, as pictured in that link. I still remember being completely blown away by how some plastic gears and colored ballpoint pens could produce a near-infinite variety of intricate geometric patterns. Yeah, I was already a bit of a geek even when I was 7 years old!

Somewhere along my meandering journey from childhood to middle age, my Spirograph set was lost. But a recent query from my wife (who has become interested in geometric designs for art quilts) rekindled my interest in this long-lost toy. I haven't gone and bought an old Spirograph set on eBay (yet...), but I've done the next best (in some ways better!) thing.

With a bit of research on Wikipedia and Wolfram MathWorld, I've learned that Spirograph produces mathematical curves called hypotrochoids and epitrochoids. In a nutshell, if you take a fixed circle, roll another circle around its inner or outer circumference, and affix a pen at some distance from the rolling circle's center, the pen traces a hypotrochoid (if the rolling circle is inside the fixed one) or an epitrochoid (if the rolling circle is outside the fixed one). The number of lobes in the pattern depends on the ratio of the sizes of the fixed and rolling circles, and the shape of the lobes (how pointy or rounded they are) is determined by both the ratio of the sizes of the circles and the distance of the pen from the moving circle's center.

It's a fairly simple matter to simulate arbitrary Spirograph patterns on a PC, and display the results in a window. I've written a simple Python script to do this—I call it Pyrograph, and you can grab the (admittedly rather primitive) v0.1 release of it here (right-click the link, and save the file locally). Update: There's a v0.2 release here, which fixes the issue when executing from within the Python Idle environment that someone reported in the comments. It has also been noted that the Windows-style line endings in the file can cause problems for Linux users ("bad interpreter" errors); Linux users should convert the line endings using the dos2unix command before attempting to run the script.

To play with the script yourself, you'll need to install the Python interpreter on your system. Python is a freely available, Open Source, cross-platform scripting language that has a huge number of add-on packages available for various application areas. For Windows, simply download and run the installer for the latest 2.x release, which should be available from this page. If you're a Tux fan, install the base Python package and the "tkinter" add-on from your Linux distro's software repository (many distros install the Python interpreter by default, so you may need to install only tkinter).

Take a look at the Pyrograph script in your favorite plain-text editor (even Notepad will do in a pinch). The Pyro method is the heart of the script; the first parameter is the radius of the fixed circle, the second parameter is the radius of the rolling circle, the third parameter is the offset of the pen from the center of the rolling circle, the fourth parameter rotates the entire pattern a specified number of degrees, the fifth parameter scales the entire pattern up or down in size (values > 1 enlarge it, values < 1 shrink it), and the sixth parameter specifies the color of the pen.

The Draw method is invoked when the script is run; it calls the Pyro method one or more times. To change the pattern, edit the Draw method. To see the pattern, just run the script (type its name in a command prompt window, or double-click on the file).

For each of the following examples, I've listed the Draw method, immediately followed by a screen capture of the pattern it produces. (Other than the Draw method, the rest of the script remains unchanged.)

    # Example #1: Simple hypotrochoid pattern, with the rolling circle fairly large and the pen near its edge
    def Draw(self):
        self.Pyro(300, 255, 220, 0, 1, "#0000c0")

    # Example #2: Same as previous, but with the pen moved in towards the center of the rolling circle
    def Draw(self):
        self.Pyro(300, 255, 80, 0, 1, "#0000c0")

    # Example #3: Hypotrochoid with a smaller radius rolling circle
    def Draw(self):
        self.Pyro(300, 45, 35, 0, 1, "#0000c0")

    # Example #4: Multiple overlaid hypotrochoids (different pen offset for each)
    def Draw(self):
        for i in range(0, 15):
            self.Pyro(300, 200, 50 + i * 10, 0, 1, "#0000c0")

    # Example #5: Same as previous, but with each iteration rotated by a multiple of 5 degrees
    def Draw(self):
        for i in range(0, 15):
            self.Pyro(300, 200, 50 + i * 10, i * 5, 1, "#0000c0")

    # Example #6: A simple epitrochoid
    def Draw(self):
        self.Pyro(150, -60, 50, 0, 1, "#0000c0")

    # Example #7: Some multi-colored epitrochoids
    def Draw(self):
        for i in range(0, 24, 4):
            self.Pyro(150, -60, 50, i, 1, "#c00000")
            self.Pyro(150, -60, 50, i + 24, 1, "#00c000")
            self.Pyro(150, -60, 50, i + 48, 1, "#0000c0")

34 comments —
Last post by just brew it! at 11:17 PM on May 5, 2008

It was twenty years ago today...
by Mike Uchima — 12:25 AM on March 31, 2008

As someone who's been building and using PCs since the 1970s, it amazes me when I look back at how far we've come since the early days. Inspired by UberGerbil's "Computer Archaeology" forum thread, I decided to do a little archaeology of my own, delving into the dark corners of my crawlspace and attic. It's going to take a while to sort through stuff and figure out what's worth sharing here, but one of the first interesting items I came across was a Byte magazine from March 1988 - exactly 20 years ago.

The feature articles for March of 1988 were "Enhanced EGA/VGA Boards" (a review of EGA and VGA graphics boards from a number of vendors) and "The New Coprocessors" (five articles about math coprocessors and floating point programming). 640x480 was still considered to be "high resolution" for a PC video card in those days, and you could easily pay upwards of $500 for the privilege. Intel's 80387 math coprocessor had debuted a few months before, and Weitek had also introduced their competing 1167 math coprocessor (which outperformed Intel's 80387 but required the installation of a $2,000 add-in card).

On the software side of things, Byte also looked at Microsoft Works 1.0 and Excel 2.0, giving both products good reviews. Since almost nobody was running Windows in those days, Excel actually came bundled with a copy of Windows 2.0!

The best part of looking at these old mags has to be the ads, though. I think they give you a great picture of where the industry was at, and they can also be good for a laugh.

Starting small, first up is an ad from Logitech touting its new mouse:

Wow, 320 DPI resolution! (Modern high-resolution mice are 1000+ DPI.) And just look at those sleek lines and that ergonomic design... not!

Next up is Toshiba's "desktop replacement" laptop computer:

Yes, 18.7 pounds was revolutionary for those days. And with a 12MHz CPU, 40MB hard drive, and the ability to connect to mainframes (gasp!), how could you possibly go wrong? Battery life was a non-issue, since you had to plug it in. I actually used a Toshiba laptop similar to this one on a couple of business trips back in the day... and yes, for its time it was quite impressive!

And then there's quad core desktop computing, 1980s style:

The Inmos Transputer (like the Weitek math coprocessor mentioned above) is one of those products that was considered quite impressive from a technical standpoint, but never gained sufficient traction in the market to become a commercial success. The company I was working for at the time evaluated the possibility of using the card on the right to do financial modeling, and even ported some of their code to run on it. Unfortunately, the overhead of breaking the problem up into chunks that could be processed in parallel by the transputers, combined with the dismal bandwidth of the ISA bus interface, meant that the modest application performance gains just weren't worth the $6,000 price tag. To put the performance in perspective compared to modern CPUs, you'd need several hundred of those Quadputer cards to provide floating point performance equivalent to a single modern quad core x86.

Last up is a memory module monstrosity from Micron, these days better known as the popular memory vendor Crucial:

Yup, that's 2MB on a full-size ISA card. 4MB if you get the daughter card option. All running at a blazing fast 12MHz!

Well, that's about it for this trip down memory lane (haha, pun intended). I'll probably make this a semi-regular feature as I go through more of the stuff I've got stashed in the crawlspace. I had hoped to find even older material (early 1980s or even 1970s), but haven't quite reached that stratum in my ongoing archaeological dig just yet. "It was thirty years ago today" doesn't have quite the same ring to it, does it?

67 comments —
Last post by Ya'akov at 1:33 AM on April 27, 2008

Bits and Bytes... V0.1
The adventure begins...
by Mike Uchima — 11:48 AM on February 26, 2008

Test... test... hey, is this thing on?

Ahh, there we go.

Allow me to introduce myself. Some of you may know me already as "just brew it!" on the TR forums. I've been an active member of the forums here since 2002; since then I've taken on an expanded role as moderator of the Distributed Computing and Developer's Den sub-forums, and (most recently) as co-administrator of the forums as a whole. I also designed and built The Beast, which Geoff has used to perform load testing in TR's two recent PSU roundups.

Jumping back a decade or two or three, I've been an incurable nerd and PC enthusiast almost as long as there have been PCs. My first PC was an IMSAI, which I built back in 1978 when I was in high school. In those days, the first step in building a PC was going down to the local Radio Shack to buy a soldering iron and a spool of solder! Most of the cards came as "kits", which typically consisted of a bare PC board, a bag of ICs and other components, a schematic, and a diagram of the board layout. Mmmm, don't you just love the smell of hot molten solder in the morning? OK, maybe not. Hmm, maybe all those lead fumes I inhaled as a teenager explains the... umm... *ahem*... but I digress. Let's move on, shall we?

I majored in Computer Science in college, and married my high school sweetheart. I've also raised three wonderful kids, none of whom are as geeky as their father. (Though my son comes close... there's hope for him yet... or should I say he's doomed?)

Over the years, I've worked as a software engineer in the telecom, finance, high-energy physics, and (most recently) defense industries. I've also built or repaired countless PCs for myself, family members, and friends. I still find computer technology—both the hardware and software aspects of it—to be endlessly fascinating; technology changes so rapidly that there's always more new stuff to learn.

Some years ago, I also became interested in craft beer. Like PCs, beer became a bit of an obsession. I took up homebrewing, joined a local homebrewing club, attended homebrewing conferences, and trained to become a certified beer judge. Lately I've also started getting into making Mead. Something interesting I've discovered is that a surprising number of people who homebrew also work in technology-related fields. Maybe that's not so surprising after all—anyone can brew beer; but to consistently brew quality beer you need to pay attention to details, document everything, and continually refine your process. In other words... it's an engineering problem!

So anyhow, getting to the point, Damage & Company have invited me to take a more active role in contributing content to the site. I'm not planning on focusing on any one particular subject area; the tentative plan is for me to do a grab bag of "How To" type articles, possibly some "quick look" reviews of hardware that doesn't merit the full TR review treatment, and other random stuff that relates to PC technology in some way (but may be a bit off the beaten path relative to what TR normally covers). Oh, and this blog, which is basically going to be me ranting about whatever geeky topic floats my boat this week.

Within limits, I'll also take requests—if there's a topic you'd like to see covered or a blog post you'd like to see expanded into a full-length article, give a holler in the blog comments! If the subject matter isn't too off-topic for TR, Damage may give the go-ahead for a feature article.

35 comments —
Last post by idchafee at 10:53 AM on March 31, 2008