davintosh

Ok, here’s a weird remote access tale, that just happens to be true…

Tonight I needed to edit some video on a computer at church — a Mac G5. That particular computer is set up for remote access by way of VNC, but is behind a pretty tightly controlled firewall. The church does have a Windows Small Business Server 2003 with Remote Web Workplace running on it that is accessible through the firewall. The problem is that Remote Web Workplace requires ActiveX to be running on the client computer, so Macs need not apply…

Or can they?

At work I have a Windows XP machine that is set up for outside access via GoToMyPC; GoToMyPC recently released a version that works great with a Mac as a connecting client… So I use my humble G4 PowerBook to open a GoToMyPC session with my work computer, then connect to Remote Web Workplace from there. Once connected I open a session on one of the Remote Workplace computers, fire up VNC, and hit Connect with the address for the G5. Three layers of security, three different ISPs & six passwords later… Can you say “latency”?

That latency is especially evident where trimming the video is concerned. Moving the Quicktime trimming controls with the mouse can only get you so close to where you need to be, so that’s followed by nudging the video with the arrow keys, at a rate of about 50 clicks per second of video. Painfully slow.

I think it might be faster to just drive out there, and save this trick for something for which it’s better suited. For.

All network interface cards have MAC addresses, a string of alphanumeric characters unique to each interface. In keeping records for the machines at work, I’ve noticed that when keying in a hardware address it’s possible to do it two-handed on a standard US QWERTY keyboard with a keypad — numeric characters are entered with the right hand and alpha characters with the left.

I don’t think that was what the designers of the ethernet protocol intended, but it’s a great unintended positive side effect. A MAC address is represented as a set of six groups of two hexadecimal digits each. Hexadecimal, a base-16 counting system, uses 0-9 and the alpha characters A-F to comprise its sixteen digits.
0=0, 1=1, 2=2, 3=3, 4=4, 5=5, 6=6, 7=7, 8=8, 9=9, 10=A, 11=B, 12=C, 13=D, 14=E, 15=F
It’s just a happy coincidence that those six characters can be struck using the fingers of the left hand on a US keyboard layout. Meaningless to most I suppose, but I found it interesting. And handy!

My kids have asked me before why it is that driving a computer-simulated car in a video game is so much different than driving a real car. My off-the-cuff answer has been that the controls in the video game are usually much cruder than those in a real car. Imagine if you were driving down the highway and your steering was controlled by two buttons for left & right, the throttle was an on-off switch, as was your brake. Controls like that in a video game make driving pretty dodgy, but if it were in real life… I’m glad I don’t have to share the road with vehicles like that! Cars would have to be just as indestructible as their game-world kin.

The guys in this video were wondering something similar; how it would work if you tried to control a real vehicle from the typical video game driving perspective. The results, even with normal vehicular controls, are pretty hilarious. (There is some foul language in the video, so keep the volume low or headphones on if there are kids nearby!)

I’m guessing the drivers could improve with a little practice. Or maybe a lot of practice.

I was digging through my Sitemeter visitor stats a few days ago, and noticed again with a bit of wonder that one of the posts that consistently sees a fair bit of traffic is the one about the 68000 dash 30fx computer I have at home. The dash 30fx a monster of a Macintosh clone that was built without Apple’s blessing in the early ’90’s. The manufacturer got away with it by building the computer around the logic board of a IIfx purchased from Apple. The IIfx was no slouch in its day, but the 30fx stepped things up to the next rung, but at a high price.

You can read more about that relic in the old post, but seeing a bump in interest on that page made me wonder whether some of that traffic might be driven by some new chatter about those computers. So I did a little searching, and came up with several Google Books hits that I hadn’t seen before. One of them was a Network World article from June 15, 1992:

The part that got me…

The network had to be Ethernet-based in order to accommodate the Macintosh equipment. But the bandwidth constraints of a conventional Ethernet LAN were insufficient for transmitting images ranging from 100M to 300M bytes in size.

That’s a blast from the past. I remember the days of 10baseT ethernet all too well, when pushing a 100MB file over an AppleTalk network would take a matter of minutes, and 300MB… Start the transfer and go take a coffee break! It makes me feel a bit old. The digital prepress shop described in the article sounds amazingly similar to to our shop at CCL where we used the dash 30fx along with a IIfx, some Quadra 950’s, a LaserWriter, a couple of Sun SPARCstation 2s (which served as raster image processors (RIPs) for a DuPont Crosfield imagesetter). Our operation was a lot smaller than the one described in the article, as we only had one Crosfield — they had ten. They may have had more equipment, but still dealt with the same constraints in moving data around the network.

I started work for CCL in 1991, and moved to the graphics department about a year later. I worked in traditional stripping, proof & platemaking for a while before transferring to the digital art department. Not long after getting in the door, the department’s tech guy decided to venture out on his own & started a digital imaging company. I was “promoted” to fill his shoes, providing tech support for the department in addition to my regular duties. In that position, one of my first tasks/learning opportunities was to move a couple of pieces of equipment around in the department, which involved making a couple of changes on the old thinnet daisy chain network. I started the job on a Friday afternoon after everybody else had left, and could not get it working again. Thinnet was as quirky as it gets; throughput may have been slow, but reliability & configuration flexibility were awful. That made the speed less of an issue I guess.

One of the projects my predecessor had started but hadn’t finished was upgrading the network in the department to 10Base-T twisted pair ethernet. The network drops were in place and most of the pieces were there, but we were still waiting on a few last pieces so we weren’t quite ready to pull the trigger on it. The trouble I had that evening helped me decide we were ready enough, so I blasted forward with the 10Base-T and figured I’d deal with the missing pieces afterward. I didn’t see much hope in getting the thinnet working, so even if I spent the whole weekend finishing the project up, I figured I could spend the same time with the thinnet and still end up with a slow dodgy network that might still not work. That turned out to be one of the best decisions I ever made. I had everything installed and working in less than an hour (after screwing around with the thinnet for four hours just trying to get it to work.) The few devices still on thinnet stayed on a little sub-network, with a Mac bridging the two segments. We limped along like that for a week or so until the rest of the equipment showed up, but just having things working — and working at five times the previous network speed — made it more than worthwhile. My boss was impressed!

I learned a lot on that first 10Base-T ethernet network; the 10 megabit speed in AppleTalk, combined with those early machines made image processing pretty time consuming. In 1992, pushing a 100MB file around the network indeed took a while, plus disk space was very expensive, so all kinds of extra work went into making things as compact as possible. Even on the state-of-the-art RIP running on that 90MHz Sparc 20 workstation, an eight-page layout literally took hours to process before it would begin imaging. A lot of times, we’d set up a layout, send it to the RIP and let the RIP chew on it overnight; if we somehow made a mistake somewhere along the line (it happened; not often, but it happened) we’d have to fix the foible & start all over again. Even before the job went to the RIP we’d examine the Quark, Illustrator & Photoshop files trying to find places we could streamline things a bit; Photoshop images that were scaled and/or rotated in Quark or Illustrator would take extra RIP time, so we’d take the time to re-do those files in Photoshop so they would be placed at 100% with no rotation.

Now though, eighteen years later, with RIPs running multiple 3GHz processors (with multiple cores), 4GB of memory, and gigabit ethernet, that same eight-page spread takes a matter of minutes to send to the RIP and for the RIP to process it. And modern operating systems, gigabit ethernet NIC’s and faster hardware make file transfers of several gigabytes pretty much a non-issue. Then there is disk space; one of the first purchases I had to make was a 1GB SCSI hard drive to replace one that had died in a Macintosh Quadra 950. I don’t remember exactly what I paid for it, but I know it was in the neighborhood of $1,000. Now you can buy a 1 terabyte drive for under $100! So with disk space so cheap and network transfer speeds so fast, the time we spent trimming file sizes and optimizing placement seems a total waste.

The years I’ve spent in this business have pretty much flown by At this point in my career, I’m probably in it for the duration. But thinking about how much things have changed since I started back in 1992 really makes me wonder what kind of changes and improvements the next 18 years will bring; cheaper, faster, smarter…

Apple just introduced the iPad, and I want one. You can read about all the details and watch the demo movie in lots of places, so I won’t spend any time on that…

I just want one.

I helped a friend set up her new 27″ iMac last weekend, and it came with the coolest new mouse… The Apple Magic Mouse.

The mouse is the button, plus it has no scroll wheel, but you can use it to scroll up, down, diagonally and sideways. Comes in one color, wireless Bluetooth, but right now is only supported for use on a Mac (Windows support is coming!) The way it works is similar to the MacBook trackpads with multiple-finger functions, but that is a couple of steps above the trackpad on my getting-older-by-the-day PowerBook G4! I want one!

Actually, these would be great for use at work; seems like I’m replacing a mouse somewhere in the building at least once a week. The failures are usually with the scroll wheels, and the Apple Mighty Mouse with its tiny little scroll ball is the worst offender. The Magic Mouse with no external moving parts should be nothing but great! And as great as this mouse is, the tablet computer that Apple is expected to announce should be nothing less than amazing.

I was digging through the system logs on the MS SQL server (SQL 2000 on a Windows Server 2003 virtual machine running inside VMWare ESXi on a monster Dell box; very cool. I’ll write about it sometime…) at work just now, trying to track down a goofy slowdown that happens on occasion, and came across this System Event…

The system uptime is 1339878 seconds.

That’s one million, three hundred thirty nine thousand, eight hundred seventy eight seconds, which translates into 22,331.3 minutes, or 372.1883 hours. Which, as everybody knows, is the same as 15.5079 days (rounded to four decimal points.) Or it could be expressed as 15 days, 12 hours, 11 minutes and 18 seconds (as calculated by a quick formula I threw together in Excel.)

Filtering through the System Events, I can see an eventlog entry for every day and every time that service had been stopped or started since November, 2007. The machine has been in operation for much longer than that (probably since 2004), counting the seconds that go by one. At. A. Time… Day in and day out. It’s useful information to be sure, but why display the time in seconds? Couldn’t the geeks in Redmond be bothered to modify that to show the time in days, hours & minutes instead? It’s a computer, for crying out loud, and most computers have plenty of extra capacity.

Seeing the time in seconds — especially in numbers that big — is absolutely meaningless to me. It’s not like running a calculation to make the time count easier to read would tax the system much… A holdover from an earlier time when every processor cycle was counted as precious? Or just an item very low on the priority list? Or maybe I just have too much time on my hands today?

I get marketing emails and newsletters on occasion from the good folks at Linotype, trying to sell me fonts. What kind of irony can come from them? Just the fact that the emails arrive in plain-text mode, like you see below:

Linotype is of course one of the premier and longest-lived font houses around. I’ve bought a number of fonts from them over the years; what they sell is of excellent quality and their site is always a source of reliable information on fonts & typography. That they send out their newsletter in plain text speaks volumes. I don’t recall making a choice between html & plain text way back when I first signed up, but it’s noteworthy that they’d even give you that choice in this day of flash and hype.

Long live Linotype!

I was in the process of setting up another new iMac for a user at work the other day, and got to looking at the hard drive — the ‘entry level’ 24″ iMac comes standard with a dual-core 2.66GHz processor, 4GB of memory and a 600GB hard drive. Much of that capacity (other than that memory) just won’t get used. There will be times when the processors will peak a bit, but most of the time they’ll be just barely above idle. And the hard drive… 600GB? On a desktop machine? If the computer were used in a home setting, that might get utilized, but here… Boy could I use some of that capacity for other stuff on the network! I guess I could just buy some cheap 100GB SATA drives and swap them out, but I’ve seen the gymnastics necessary to replace a drive in an iMac, and I don’t want to go through that any more than absolutely necessary.

I remember back when Apple was first rolling out OS X, there was talk of these super apps that would allow us to tap into some of that unused processing power by creating a distributed network computer by linking the computers on a network together; if one computer had a huge task of some sort to complete and other computers on the network had spare processor cycles available, there’d be some sharing going on, and you could get more done. At least that was the idea, but I haven’t heard much about distributed computer grid clusters since the big splash about using a host of Macs to create a monster grid computer. Xgrid sharing lives on, and even has a checkbox to enable it in the Sharing Preference Panel in Mac OS 10.5 (and maybe earlier.) Years ago when it might take a raster image processor (RIP) multiple hours to chew through an eight-page layout I would’ve have loved to put something like this to work, but today with the typical tasks done on the typical desktop computer in a print shop or an office environment, and without some monstrously processor-intensive task that needs to be done, I don’t really see much point in messing with it.

What I would like to see though is some kind of distributed disk sharing; that iMac I set up today starts out with a whopping big 600GB drive; after loading all the software on it there was still an easy 500GB… And that computer is one of three that I set up recently, and one of five of the same configuration. If I were to partition the disks in each of those machines to set aside half of the available space I’d have an easy terabyte and a half of disk space that could be used for other stuff.

What if there was some way of joining the disks on multiple computers over the network to create a disk array of sorts… A local area network RAID array. Think of a RAID array with the network acting as the interface card and some software on a server striping the bits & bytes across the disks. In all my digging through Google and other search engines, I haven’t found anything like what I’m thinking of; either I’m not asking the right questions or it hasn’t been done yet. If not, that’s too bad, because I think there’s a lot of potential there, but I can also understand some of the obstacles to making it work. The biggest issue is probably that the network can be a lot more fragile than the hardware & software that it takes to make a RAID array in a server or external box work. A mirrored drive in a RAID 1 arrangement would probably work best, as the other RAID levels with the data striped across multiple volumes would require a higher level of availability for the disks than might be possible.

But you know, since it doesn’t look like using that disk space for live files will work any time soon, maybe I can still put it to use for backups; set Retrospect up to use that space for backing stuff on the server up to disk, just for extra redundancy… Hmmm… Might have to play with that a bit…

Pretty much, Apple and Dell are the only ones in this industry making money. They (Dell) make it by being Wal-Mart. We make it by innovation.

—
Steve Jobs.

This quote was found at a site I bumped into tonight; Minimal Mac. A little heavy on the hoity-toity Mac user stereotype, but they’ve got some good info.