Tag Archives: Apple

Unix Dying? Ha!

Julie Sartain over at Network World published a piece today called “The last days of Unix.” In, largely citing Gartner analysis, she posits that Unix is slowly dying.

To that, I say, “fat chance.” Reading the article, the numbers are reasonably compelling, but I think they tell a different story than what Gartner and Sartain are saying.

The article appears to be measuring pervasiveness through expenditure, and particularly server expenditures. By that measure, Gartner’s data is showing the levels have peaked and will slowly be declining over time. And generally, that measure is probably accurate.

But that’s a little like saying carbohydrates are going out of fashion because some Panera Bread franchises are closing. Measuring Unix’s staying power through people purchasing specific servers is probably not the best way to do it.

If you are trying to get a true measure of Unix’s pervasiveness over time, it would seem to be far better to look at shipments of…Unix. And it’s variants, of course (although the article differentiates between Unix and Linux, et al, it seems a bit of a spurious distinction). So look at the dedicated server shipments, sure, but also at Mac OS X (hello, Unix kernel), and RedHat/Fedora and CentOS and Debian and Solaris and …well, you get the idea.

Looking only at the sales of big iron itself says more, I think, about the decline in purchasing of big iron. Recent articles in mass media have talked about the slowness in tech spending, driven in part by companies’ move into the cloud for computing power. Well, that’s one example (of several) where previous orders for big iron just aren’t happening anymore, unless you’re someone like Amazon or Google – and they both build their own custom boxes.

So for those denizens of bash, the wizards of tcsh and the valiant vi users, fear not. Rumors of the death of Unix appear, to me, to be greatly exaggerated.

Retro Tech: Beagle Bros

Back when I was trying to figure out this whole technology stuff, The Great Migration happened. For me, that was the migration from a mainframe you had to drive (or, in my case, take the bus) to see and use to a computer you could just go to your room to use. And my first computer (before the TI, before the CoCo, before the C64, before all the rest) was an Apple ][.

Now this is not the time to rhapsodize nostalgic for the Apple ][ per se. But the environment around that computer encouraged hobbyists, students — and it encouraged fun. And one of the leading fun-makers was a software company called Beagle Bros.

They were weird. They were fun. They were whimsical. They’d put code snippets or bits of hexadecimal in their ads that would reveal funny lines, or a previously unknown feature in the computer’s code. Their whole purpose seemed like it was to enable hobbyists to dig ever deeper into the machine and get ever more out.

Take, for instance, their Apple Mechanic software. With it, I could create my own shape tables to use in my little hobby games. I could make ‘em look like they were professionally done. And this was in 1982!

Who else (before Clarus the dogcow) could teach you how to make your computer moo? (CALL 985, by the way.) Who else released so much professional software that was unprotected with code listings available, so you could see how it was done and try it yourself? Who else ran their own comic strip in their catalogs?

And perhaps most tellingly, who else had a software company (now gone) that inspired its own online museum? There aren’t many. And few had as much an impact on an entire generation of today’s programmers.

Perhaps it’s nostalgia, but Beagle Bros was ahead of its time in creating and putting forth a culture that engaged its customers (contests, for instance), respected them (no copy-protection, just a request not to pirate), and supported them (the PEEKs & POKEs poster alone was huge support). Many a company today could take a page from their playbook.

The Cobbler’s Kids are Shoeless

There’s a 16th-century proverb that goes something like, “The shoemaker’s children go barefoot.” Or unshod. Or something olde-timey like that. But however you phrase it, the sentiment certainly seems true today.

Last week, Apple announced that their developer site was hacked, and that potentially thousands of developers’ emails and other info may have been compromised. The hack (and the hacker) have since been called into question, and the real scope of the intrusion is unclear. But, to put it mildly, it ain’t good.

If Apple, with all of its resources and intricate technological knowledge, can’t keep it’s, ahem, stuff together with basic security, it seems like there’s not a great amount of hope for the rest of us. At least under the current security regime. Some of this is certainly due to neglect close to home — the shoemaker/cobbler proverb again — but much of it is based on how we handle security in general.

The username/password or email/password security approach just doesn’t work. It really doesn’t. Oh, sure, you might argue, it’s ubiquitous, so it must work fine. But there are SO many examples of breaches that something is amiss, and even where there aren’t breaches, it may just as likely be because nobody has really targeted that system yet.

So if not that, then what? Biometrics? RSA keys for everyone? Implanted chip under the skin? How apocalyptic sci-fi movie do we want to get?

Frankly, I don’t know. Each of those approaches has definite pros and cons, including a glimpse of dystopia. But I know this: what we have now is not working. And perhaps this is just another example of Apple leading the way.

Not that they were wanting to lead in this particular area… Apple, get your kids some shoes!

WWDC 2013: Getting Out of the Way

Apple’s Worldwide Developer Conference wrapped up last week, and amidst the announcements about new user-facing features in the next versions of iOS and Mac OS X (versions 7 and Mavericks, respectively), there were a ton of announcements and sessions about new developer features as well. A new version of Xcode was featured, along with a slew of new and revised APIs.

As I watched the sessions related to one of those APIs, Sprite Kit (which is a pretty amazing new gaming engine that includes physics, particle effects, and 2D graphics awesomeness), an offhanded comment by the presenter resonated with me. The intention of the new toolkit (and, ya gotta hope, other changes) is for the technical environment and hurdles to fade into the background, and to make the execution of the content as seamless as possible.

The point is to get out of the way.

It’s a worthy goal, and certainly by eliminating the need for some game developers to deal with a third-party toolkit, I’m sure Apple has made some headway there. But thinking more broadly, there’s still a ways to go.

Think for a minute about a technologically-proficient non-programmer who wants to build an app. What are they to do?

Learn a language (in this case, probably Objective-C), learn a development environment (e.g., Xcode), join the developer program, and learn the APIs. While there are many people who are doing just that, it seems like there are ways to better get out of the way.

For some examples, we can look to history. In the earlier days of the Mac, there was HyperCard. Bill Atkinson created the visual hypermedia authoring tool nearly 30 years ago, almost a decade before the WWW showed everyone how powerful hyperlinks could be. With HyperCard (and its successors, including SuperCard, which is still shipping and works on current OSes), an elementary-school student could create an app. Little to no formal “programming” — just point, click, and develop.

For more sophisticated applications, there were graphical development environments like Prograph (now resurrected as Marten). In these IDEs, you still need a knowledge of the APIs, but you string the calls together graphically, with your custom functions and routines represented as graphical units that can be strung together. It requires more knowledge than HyperCard, but definitely less than the current standard toolsets.

But back to the present day. Programming is still a niche skillset, despite the ubiquity of technology in our lives. Students in middle and high schools are showing middling interest at best. One (of many) reasons that’s true has to be the lack of an easy way to get novices building sophisticated apps. The tools and processes are just too much “in the way.”

Apple’s moves in the direction of easy and sophisticated development are admirable. But there’s a long way to go to realize the promise that Atkinson made back in 1985.