Month: August 2002

maybe they should give it away

HyperCard Forgotten, but Not Gone

IHug [Int’l HyperCard User Group] wants to see HyperCard ported to run on Mac OS X, and the incorporation of overdue features, like fully integrated color. HyperCard is still, at heart, black and white.

IHug campaigned vigorously for several years, with little luck. Their efforts culminated in a meeting with Phil Schiller, Apple’s head of worldwide marketing, who reportedly ended up asking them, “But how do we sell it?” Clearly, Schiller wasn’t convinced by iHug’s answers.

I loved HyperCard. It was easy, useful and in many cases all you needed. Even when it wasn’t it could get you a lot of the way there.

Perhaps IHug should turn Schiller’s question around, and ask why doesn’t Apple make HyperCard open source? They don’t care about it, and IHug does. If they’re willing to do it with Darwin et al, this should be an easy one.

Thanks to Frank for this one.

the other side of the coin

In depths of World War One, as the red-faced, potbellied generals dithered safely behind the lines and British losses mounted frighteningly , Churchill referred to the brave British Tommies embattled in the muddy trenches as ‘lions led by donkeys …’

lions led by donkeys

There’s another aspect of this discussion of the Seattle job market and how tough it is right now.

Even during the boom and now following it, the executive corps of many tech companies was filled with people who had very little or no experience as managers and had never experienced a down market. Couple that with business plans and internal goals that had nothing to do with the longterm survival of a business, and you have a real mess.

As a hiring manager, I had hiring goals or headcount requirements I was to meet, not that I couldn’t go over, as is usually the case. I was expected to hire people, and not doing so was not perceived as prudence but lack of effort or commitment. That, as they say, is no way to run a railroad.

The people now doing the hiring as the same as were there in the boom times: the best way to get rid of any “retaliation” would be to turn them out on the street and hire professionals.

The hiring process at many tech firms seems to be a simple keyword search, with no analysis of what the applicant’s actual strengths are. Inexperience then looks more like incompetence . . . . .

plus ca change

“Some employers seem to be retaliating in this buyer’s market for the perceived arrogance of job seekers during the boom years,” said Janet Scarborough, a Seattle-area career counselor who hears countless horror stories. “Now that the supply-and-demand situation has changed, some employers are acting in unnecessarily callous or punitive ways.”

Salon.com article

Paul Beard, 38, the former director of technical operations for Fizzylab, a now defunct Internet infrastructure company, says that he’s been looking for a job in I.T. since Jan. 19. “It’s pretty bad. There are so many layoffs, and so many people out at the same time, and nobody is doing much hiring. They’re taking a wait-and-see attitude. ‘We’re waiting until second quarter before we make any decisions.’ It’s a buyer’s market, and the buyers aren’t buying.”

if I was a warez d00d

I have a copy of Microsoft Office 2000 Small Business which I legally own but I lack a license key (note to self: write the key on the CD next time, in case the jewel case goes adrift).

When I rebuilt my laptop the other day, I reinstalled Win2K from the recovery disk and discovered I had the Office disk. But alas, it looks to be a coaster. An OS is only as good as the apps it runs: I guess I could try [open|star]office . . . . .

the real switch for Apple?

Apple said to be eyeing Intel chip — The Washington Times

One thing that might help Apple make the switch is the growing popularity of its Mac OS X operating system, which is based on Unix. Unix, in turn, can run very nicely on Intel processors, so converting OS X to run on Intel microprocessors might not be that difficult.

Of course, Darwin, the core of OS X, already runs on x86 hardware. So this is closer to reality than this article suggests.

Also, recall that BeOS ran on PPC hardware first (their own, then Apple’s) and then was ported across to x86. The official story behind the lack of support for the PowerPC G3/G4s in BeOS was that Apple wasn’t giving Be access to hardware information. My theory was that Intel, in doing a lot of the work on the port to their hardware, had a hand in that. Apple’s loss, I think. Perhaps we’re seeing the continuation of the NeXTisation of Apple. NeXT started as PPC hardare vendor, then became a software only shop. Could Steve be eyeing the same move again?
Thanks to John for the tip.

further fink fun: resolution

I think my fink installation is now unwedged. The problem stemmed from mixing up the stable and unstable trees, as far as I can tell.

The package tree is subdivided into local, stable, and unstable, and the (un)stable trees are further divided into main and crypto.

[/Users/paul]:: more /sw/etc/fink.conf
# Fink configuration, initially created by bootstrap.pl
Basepath: /sw
RootMethod: sudo
#Trees: local/main stable/main stable/crypto local/bootstrap
Trees: local/main unstable/main unstable/crypto stable/main stable/crypto local/
bootstrap
Mirror-ctan: ftp://tug.ctan.org/tex-archive/
Mirror-gimp: ftp://ftp.gimp.org/pub
Mirror-gnome: ftp://ftp.gnome.org/pub/GNOME/
Mirror-gnu: ftp://ftp.gnu.org/gnu
MirrorContinent: nam
MirrorCountry: nam-us
ProxyPassiveFTP: true
Verbose: true

So I removed xfree86-base, using the suggestion I got from a new user on the fink-users list.

I ran sudo dpkg –remove –force-depends xfree86-base and then switched from using the unstable trees to just the stable and local (see the commented out line above).

I then installed an older version of xfree86-base with dpkg. That made X work again. As a side note, at no time during this ordeal did any of the fink-managed applications fail to work: the only one that failed was fink itself.

Then a test of fink selfupdate-cvs and fink update-all. The xfree86 version I installed was upgraded:

The following 4 packages will be installed or updated:
arts docbook-dtd wget xfree86-base
The following additional package will be installed:
qt3


And here’s what xfree86 looks like now:

[/sw/lib/perl5/darwin/auto]# fink list xfree86
Information about 1401 packages read in 44 seconds.


system-xfree86 4.2-1 Placeholder package for manually installe…
i xfree86-base 4.2.0-11 XFree86 libraries, utilities, clients and…
xfree86-rootles 4.2.0-11 XFree86 libraries, utilities, clients and…
xfree86-server 4.2.0-2 XFree86 display server (stable release)

There may still be some problem in the database in that fink still thinks it has Storable.pm installed and I have deinstalled it as well as removing it from the filesystem.

Hmm, I just told fink to remove it and this time, it shows it as uninstalled. Good.

I’ll have to wait a couple of days and a couple of CVS runs to see if this fixes it. But it looks good so far.

It looks like some way of enforcing database integrity and sane config files could improve fink’s robustness. Curious why fink’s config data isn’t in an XML/plist format: that might lend itself to more rigorous parsing (since xml parsing libs are installable with fink itself). There were some errors in my fink.conf file, as was pointed out, and perhaps that introduced the error.

Making the corrections to the fink.conf file weren’t enough to fix this, nor was removing xfree86-base by itself. Losing the unstable trees and then reinstalling xfree86-base, even an older version, did the trick. At the point I could reinstate the unstable trees and the updates would work as expected.

if I could take it all back, would I?

Google Search: paulbeard@mac.com fink
Google Search: pkdb1@home.com fink

It seems strange to read how many positive things I had to say about the Fink project when I contrast it with my current opinion.

I’m still working on repairing my broken installation. Compiles take a long time on a 350 MHz machine, so progress is slow. I suppose I could save time and download the .deb files.

It would, of course, save a lot of time if anyone on the fink team knew how the package management software actually worked. And maybe someone does and they just weren’t checking mail this weekend. My fault for expecting anything on a weekend.

I would have been quite happy if someone — anyone — had said they didn’t know but they knew who might, or asked for information that was in some way relevant. But trotting out the same old gripes about where perl libraries get installed (answer: where perl can find them) is useless and annoying. Incidentally, I removed Storable.pm from the fink installation — retaining it in perl’s @INC path — and nothing broke. Fancy that.

Discovering that the manual page contradicts reality makes me wonder if anyone actually does a baseline install/regression test of new releases as they come out. I know the answer to that already.

At some point, my anger will subside but for now it seems to be simmering nicely.